Configuring networking services

Procedure

1. Open the OpenStackControlPlane CR definition file, openstack_control_plane.yaml.

2. Add the following ovnController configuration, including nicMappings, to the ovn service configuration:

   apiVersion: core.openstack.org/v1beta1
   kind: OpenStackControlPlane
   metadata:
     name: openstack-control-plane
     namespace: openstack
   spec:
   ...
     ovn:
       template:
         ovnController:
           networkAttachment: tenant
           nicMappings:
             <network_name: nic_name>

   • Replace <network_name> with the name of the physical provider network your gateway is on. This should match the value of the --provider-physical-network argument to the openstack network create command used to create the network. For example, datacentre.
   • Replace <nic_name> with the name of the NIC connecting to the gateway network, such as enp6s0.
   • Optional: Add additional <network_name>:<nic_name> pairs under nicMappings as required.

3. Update the control plane:

   $ oc apply -f openstack_control_plane.yaml -n openstack

   The ovn-operator creates the network attachment definitions, adds them to the pods, creates an external bridge, and configures external-ids:ovn-bridge-mappings. The setting external-ids:ovn-cms-options=enable-chassis-as-gw is configured by default.

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. Verify that ovn-controller and ovn-controller-ovs pods are running, and that the number of running pods is equal to the number of OCP control plane nodes where OpenStack control plane services are running.

Verification

1. Run a remote shell command on the OpenStackClient pod to confirm that the OVN Controller Gateway Agents are running on the control plane nodes:

   $ oc rsh -n openstack openstackclient openstack network agent list

   Example output

   +--------------------------------------+------------------------------+---------+
   | ID                                   | agent_type                   | host    |
   +--------------------------------------+----------------------------------------+
   | 5335c34d-9233-47bd-92f1-fc7503270783 | OVN Controller Gateway agent | ctrl0   |
   | ff66288c-5a7c-41fb-ba54-6c781f95a81e | OVN Controller Gateway agent | ctrl1   |
   | 5335c34d-9233-47bd-92f1-fc7503270783 | OVN Controller Gateway agent | ctrl2   |
   +--------------------------------------+----------------------------------------+

Procedure

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

2. If there is an ovnController section:

   1. Remove the ovnController section.

   2. Update the control plane:

      $ oc apply -f openstack_control_plane.yaml -n openstack

Procedure

1. Open the OpenStackDataPlaneNodeSet CR definition file for the node set you want to update, for example, my_data_plane_node_set.yaml.

2. Add the required network configuration or modify the existing configuration. Place the configuration in the edpm_network_config_template under ansibleVars:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: my-data-plane-node-set
   spec:
     ...
     nodeTemplate:
       ...
       ansible:
         ansibleVars:
           edpm_network_config_template: |
             ---
             Network configuration options here
             ...

   When modifying your network configuration, refer to Section 4.2, “Network interface configuration options”.

3. Save the OpenStackDataPlaneNodeSet CR definition file.

4. Apply the updated OpenStackDataPlaneNodeSet CR configuration:

   $ oc apply -f my_data_plane_node_set.yaml

5. Verify that the data plane resource has been updated:

   $ oc get openstackdataplanenodeset

   Sample output

   NAME                     STATUS MESSAGE
   my-data-plane-node-set   False  Deployment not started

6. Create a file on your workstation to define the OpenStackDataPlaneDeployment CR, for example, my_data_plane_deploy.yaml:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: my-data-plane-deploy

   Tip

   Give the definition file and the OpenStackDataPlaneDeployment CR a unique and descriptive name that indicates the purpose of the modified node set.

7. Add the OpenStackDataPlaneNodeSet CR that you modified:

   spec:
     nodeSets:
       - my-data-plane-node-set

8. Save the OpenStackDataPlaneDeployment CR deployment file.

9. Deploy the modified OpenStackDataPlaneNodeSet CR:

   $ oc create -f my_data_plane_deploy.yaml -n openstack

   You can view the Ansible logs while the deployment executes:

   $ oc get pod -l app=openstackansibleee -n openstack -w
   
   $ oc logs -l app=openstackansibleee -n openstack -f \
   --max-log-requests 10

10. Verify that the modified OpenStackDataPlaneNodeSet CR is deployed:

    Example

    $ oc get openstackdataplanedeployment -n openstack

    Sample output

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     Setup Complete

11. Repeat the oc get command until you see the NodeSet Ready message:

    Example

    $ oc get openstackdataplanenodeset -n openstack

    Sample output

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     NodeSet Ready

    For information on the meaning of the returned status, see Data plane conditions and states in the Deploying Red Hat OpenStack Services on OpenShift guide.

Procedure

1. For unprovisioned nodes, create the SSH key pair for Ansible:

   $ ssh-keygen -f <key_file_name> -N "" -t rsa -b 4096

   • Replace <key_file_name> with the name to use for the key pair.

2. Create the Secret CR for Ansible and apply it to the cluster:

   $ oc create secret generic dataplane-ansible-ssh-private-key-secret \
   --save-config \
   --dry-run=client \
   --from-file=ssh-privatekey=<key_file_name> \
   --from-file=ssh-publickey=<key_file_name>.pub \
   [--from-file=authorized_keys=<key_file_name>.pub] -n openstack \
   -o yaml | oc apply -f -

   • Replace <key_file_name> with the name and location of your SSH key pair file.
   • Optional: Only include the --from-file=authorized_keys option for bare-metal nodes that must be provisioned when creating the data plane.

3. If you are creating Compute nodes, create a secret for migration.

   1. Create the SSH key pair for instance migration:

      $ ssh-keygen -f ./nova-migration-ssh-key -t ecdsa-sha2-nistp521 -N ''

   2. Create the Secret CR for migration and apply it to the cluster:

      $ oc create secret generic nova-migration-ssh-key \
      --save-config \
      --from-file=ssh-privatekey=nova-migration-ssh-key \
      --from-file=ssh-publickey=nova-migration-ssh-key.pub \
      -n openstack \
      -o yaml | oc apply -f -

4. For nodes that have not been registered to the Red Hat Customer Portal, create the Secret CR for subscription-manager credentials to register the nodes:

   $ oc create secret generic subscription-manager \
   --from-literal rhc_auth='{"login": {"username": "<subscription_manager_username>", "password": "<subscription_manager_password>"}}'

   • Replace <subscription_manager_username> with the username you set for subscription-manager.
   • Replace <subscription_manager_password> with the password you set for subscription-manager.

5. Create a Secret CR that contains the Red Hat registry credentials:

   $ oc create secret generic redhat-registry --from-literal edpm_container_registry_logins='{"registry.redhat.io": {"<username>": "<password>"}}'

   • Replace <username> and <password> with your Red Hat registry username and password credentials.

     For information about how to create your registry service account, see the Knowledge Base article Creating Registry Service Accounts.

6. If you are creating Compute nodes, create a secret for libvirt.

   1. Create a file on your workstation named secret_libvirt.yaml to define the libvirt secret:

      apiVersion: v1
      kind: Secret
      metadata:
       name: libvirt-secret
       namespace: openstack
      type: Opaque
      data:
       LibvirtPassword: <base64_password>

      • Replace <base64_password> with a base64-encoded string with maximum length 63 characters. You can use the following command to generate a base64-encoded password:

        $ echo -n <password> | base64

        Tip

        If you do not want to base64-encode the username and password, you can use the stringData field instead of the data field to set the username and password.

   2. Create the Secret CR:

      $ oc apply -f secret_libvirt.yaml -n openstack

7. Verify that the Secret CRs are created:

   $ oc describe secret dataplane-ansible-ssh-private-key-secret
   $ oc describe secret nova-migration-ssh-key
   $ oc describe secret subscription-manager
   $ oc describe secret redhat-registry
   $ oc describe secret libvirt-secret

Procedure

1. Create a file on your workstation named openstack_preprovisioned_networker_node_set.yaml to define the OpenStackDataPlaneNodeSet CR:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: networker-nodes
     namespace: openstack
   spec:
     env:
       - name: ANSIBLE_FORCE_COLOR
         value: "True"

   • name - The OpenStackDataPlaneNodeSet CR name must be unique, contain only lower case alphanumeric characters and - (hyphens) or . (periods), start and end with an alphanumeric character, and have a maximum length of 53 characters. If necessary, replace the example name networker-nodes with a name that more accurately describes your node set.
   • env - Optional: a list of environment variables to pass to the pod.

2. Include the services field to override the default services. Remove the nova, libvirt, and other services that are not required by a Networker node:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: networker-nodes
     namespace: openstack
   spec:
   ...
     services:
      - redhat
      - bootstrap
      - download-cache
      - reboot-os
      - configure-ovs-dpdk
      - configure-network
      - validate-network
      - install-os
      - configure-os
      - ssh-known-hosts
      - run-os
      - install-certs
      - ovn
      - neutron-metadata
      - neutron-dhcp

   • configure-ovs-dpdk - The configure-ovs-dpdk service is required only when DPDK nics are used in the deployment.
   • neutron-metadata - The neutron-metadata service is required only when SR-IOV ports are used in the deployment.
   • neutron-dhcp - You can optionally run the neutron-dhcp service on your Networker nodes. You might not need to use neutron-dhcp with OVN if your deployment uses DHCP relays, or advanced DHCP options that are supported by dnsmasq but not by the OVN DHCP implementation. .

3. Connect the data plane to the control plane network:

   spec:
     ...
     networkAttachments:
       - ctlplane

4. Enable the chassis as gateway:

   spec:
   ...
     nodeTemplate:
       ansible:
       ...
       edpm_enable_chassis_gw: true

5. Specify that the nodes in this set are pre-provisioned:

   spec:
   ...
     nodeTemplate:
       ansible:
       ...
       edpm_enable_chassis_gw: true
       ...
      preProvisioned: true

6. Add the SSH key secret that you created so that Ansible can connect to the data plane nodes:

     nodeTemplate:
       ansibleSSHPrivateKeySecret: <secret-key>

   • Replace <secret-key> with the name of the SSH key Secret CR you created for this node set in <link>[Creating the data plane secrets], for example, dataplane-ansible-ssh-private-key-secret.
7. Create a Persistent Volume Claim (PVC) in the openstack namespace on your Red Hat OpenShift Container Platform (RHOCP) cluster to store logs. Set the volumeMode to Filesystem and accessModes to ReadWriteOnce. Do not request storage for logs from a PersistentVolume (PV) that uses the NFS volume plugin. NFS is incompatible with FIFO and the ansible-runner creates a FIFO file to store logs. For information about PVCs, see Understanding persistent storage in the RHOCP Storage guide and Red Hat OpenShift Container Platform cluster requirements in Planning your deployment.

8. Enable persistent logging for the Networker nodes:

     nodeTemplate:
       ...
       extraMounts:
         - extraVolType: Logs
           volumes:
           - name: ansible-logs
             persistentVolumeClaim:
               claimName: <pvc_name>
           mounts:
           - name: ansible-logs
             mountPath: "/runner/artifacts"

   • Replace <pvc_name> with the name of the PVC storage on your RHOCP cluster.

9. Specify the management network:

     nodeTemplate:
       ...
       managementNetwork: ctlplane

10. Specify the Secret CRs used to source the usernames and passwords to register the operating system of the nodes that are not registered to the Red Hat Customer Portal, and enable repositories for your nodes. The following example demonstrates how to register your nodes to Red Hat Content Delivery Network (CDN). For information about how to register your nodes with Red Hat Satellite 6.13, see Managing Hosts.

      nodeTemplate:
        ...
        ansible:
          ansibleUser: cloud-admin
          ansiblePort: 22
          ansibleVarsFrom:
            - secretRef:
                name: subscription-manager
            - secretRef:
                name: redhat-registry
          ansibleVars:
            rhc_release: 9.4
            rhc_repositories:
                - {name: "*", state: disabled}
                - {name: "rhel-9-for-x86_64-baseos-eus-rpms", state: enabled}
                - {name: "rhel-9-for-x86_64-appstream-eus-rpms", state: enabled}
                - {name: "rhel-9-for-x86_64-highavailability-eus-rpms", state: enabled}
                - {name: "fast-datapath-for-rhel-9-x86_64-rpms", state: enabled}
                - {name: "rhoso-18.0-for-rhel-9-x86_64-rpms", state: enabled}
                - {name: "rhceph-7-tools-for-rhel-9-x86_64-rpms", state: enabled}
            edpm_bootstrap_release_version_package: []

    • ansibleUser - The user associated with the secret you created in <link>[Creating the data plane secrets].

    • ansibleVars - The Ansible variables that customize the set of nodes. For a list of Ansible variables that you can use, see https://openstack-k8s-operators.github.io/edpm-ansible/.

      For a complete list of the Red Hat Customer Portal registration commands, see https://access.redhat.com/solutions/253273. For information about how to log into registry.redhat.io, see https://access.redhat.com/RegistryAuthentication#creating-registry-service-accounts-6.

11. Add the network configuration template to apply to your Networker nodes.

      nodeTemplate:
        ...
        ansible:
          ...
          ansibleVars:
          ...
      nodes:
    
           ...
            neutron_physical_bridge_name: br-ex
            neutron_public_interface_name: eth0
            edpm_network_config_nmstate: true
            edpm_network_config_update: false

    • edpm_network_config_nmstate - Sets the os-net-config provider to nmstate. The default value is true. Change it to false only if a specific limitation of the nmstate provider requires you to use the ifcfg provider. For more information on advantages and limitations of the nmstate provider, see https://docs.redhat.com/en/documentation/red_hat_openstack_services_on_openshift/18.0/html/planning_your_deployment/plan-networks_planning#plan-os-net-config_plan-network in Planning your deployment.

    • edpm_network_config_update - When deploying a node set for the first time, set the edpm_network_config_update variable to false. If you later modify edpm_network_config_template, first set edpm_network_config_update to true. After you complete the update, reset it to false.

      Important

      After an edpm_network_config_template update, you must reset edpm_network_config_update to false. Otherwise, the nodes could lose network access. Whenever edpm_network_config_update is true, the updated network configuration is reapplied every time an OpenStackDataPlaneDeployment CR is created that includes the configure-network service that is a member of the servicesOverride list.

      The following example applies a VLANs network configuration to a set of the data plane Networker nodes with DPDK:

              edpm_network_config_template: |
                ...
                {% set mtu_list = [ctlplane_mtu] %}
                {% for network in nodeset_networks %}
                {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
                {%- endfor %}
                {% set min_viable_mtu = mtu_list | max %}
                network_config:
                - type: ovs_user_bridge
                  name: {{ neutron_physical_bridge_name }}
                  mtu: {{ min_viable_mtu }}
                  use_dhcp: false
                  dns_servers: {{ ctlplane_dns_nameservers }}
                  domain: {{ dns_search_domains }}
                  addresses:
                  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }}
                  routes: {{ ctlplane_host_routes }}
                  members:
                  - type: ovs_dpdk_port
                    name: dpdk0
                    members:
                    - type: interface
                      name: nic1
      
      
                - type: linux_bond
                  name: bond_api
                  use_dhcp: false
                  bonding_options: "mode=active-backup"
                  dns_servers: {{ ctlplane_dns_nameservers }}
                  members:
                  - type: interface
                    name: nic2
                    primary: true
      
      
                - type: vlan
                  vlan_id: {{ lookup('vars', networks_lower['internalapi'] ~ '_vlan_id') }}
                  device: bond_api
                  addresses:
                  - ip_netmask: {{ lookup('vars', networks_lower['internalapi'] ~ '_ip') }}/{{ lookup('vars', networks_lower['internalapi'] ~ '_cidr') }}
      
      
                - type: ovs_user_bridge
                  name: br-link0
                  use_dhcp: false
                  ovs_extra: "set port br-link0 tag={{ lookup('vars', networks_lower['tenant'] ~ '_vlan_id') }}"
                  addresses:
                  - ip_netmask: {{ lookup('vars', networks_lower['tenant'] ~ '_ip') }}/{{ lookup('vars', networks_lower['tenant'] ~ '_cidr')}}
                  members:
                  - type: ovs_dpdk_bond
                    name: dpdkbond0
                    mtu: 9000
                    rx_queue: 1
                    ovs_extra: "set port dpdkbond0 bond_mode=balance-slb"
                    members:
                    - type: ovs_dpdk_port
                      name: dpdk1
                      members:
                      - type: interface
                        name: nic3
                    - type: ovs_dpdk_port
                      name: dpdk2
                      members:
                      - type: interface
                        name: nic4
      
      
                - type: ovs_user_bridge
                  name: br-link1
                  use_dhcp: false
                  members:
                  - type: ovs_dpdk_bond
                    name: dpdkbond1
                    mtu: 9000
                    rx_queue: 1
                    ovs_extra: "set port dpdkbond1 bond_mode=balance-slb"
                    members:
                    - type: ovs_dpdk_port
                      name: dpdk3
                      members:
                      - type: interface
                        name: nic5
                    - type: ovs_dpdk_port
                      name: dpdk4
                      members:
                      - type: interface
                        name: nic6
              neutron_physical_bridge_name: br-ex

      The following example applies a VLANs network configuration to a set of data plane Networker nodes without DPDK:

      edpm_network_config_template: |
                …---
                {% set mtu_list = [ctlplane_mtu] %}
                {% for network in nodeset_networks %}
                {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
                {%- endfor %}
                {% set min_viable_mtu = mtu_list | max %}
                network_config:
                  - type: ovs_bridge
                    name: {{ neutron_physical_bridge_name }}
                    mtu: {{ min_viable_mtu }}
                    use_dhcp: false
                    dns_servers: {{ ctlplane_dns_nameservers }}
                    domain: {{ dns_search_domains }}
                    addresses:
                      - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_cidr }}
                    routes: {{ ctlplane_host_routes }}
                    members:
                      - type: interface
                        name: nic2
                        mtu: {{ min_viable_mtu }}
                        # force the MAC address of the bridge to this interface
                        primary: true
                {% for network in nodeset_networks %}
                      - type: vlan
                        mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
                        vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
                        addresses:
                          - ip_netmask: >-
                              {{
                                lookup('vars', networks_lower[network] ~ '_ip')
                              }}/{{
                                lookup('vars', networks_lower[network] ~ '_cidr')
                              }}
                        routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
                {% endfor %}

      For more information about data plane network configuration, see Customizing data plane networks in Configuring network services.

12. Add the common configuration for the set of nodes in this group under the nodeTemplate section. Each node in this OpenStackDataPlaneNodeSet inherits this configuration. For information about the properties you can use to configure common node attributes, see OpenStackDataPlaneNodeSet CR spec properties in the Deploying Red Hat OpenStack Services on OpenShift guide.

13. Define each node in this node set:

    ...
      nodes:
        edpm-networker-0:
          hostName: networker-0
          networks:
          - name: ctlplane
            subnetName: subnet1
            defaultRoute: true
            fixedIP: 192.168.122.100
          - name: internalapi
            subnetName: subnet1
            fixedIP: 172.17.0.100
          - name: storage
            subnetName: subnet1
            fixedIP: 172.18.0.100
          - name: tenant
            subnetName: subnet1
            fixedIP: 172.19.0.100
          ansible:
            ansibleHost: 192.168.122.100
            ansibleUser: cloud-admin
            ansibleVars:
              fqdn_internal_api: edpm-networker-0.example.com
        edpm-networker-1:
          hostName: edpm-networker-1
          networks:
          - name: ctlplane
            subnetName: subnet1
            defaultRoute: true
            fixedIP: 192.168.122.101
          - name: internalapi
            subnetName: subnet1
            fixedIP: 172.17.0.101
          - name: storage
            subnetName: subnet1
            fixedIP: 172.18.0.101
          - name: tenant
            subnetName: subnet1
            fixedIP: 172.19.0.101
          ansible:
            ansibleHost: 192.168.122.101
            ansibleUser: cloud-admin
            ansibleVars:
              fqdn_internal_api: edpm-networker-1.example.com

    • edpm-networker-0 - The node definition reference, for example, edpm-networker-0. Each node in the node set must have a node definition.
    • networks - Defines the IPAM and the DNS records for the node.
    • fixedIP - Specifies a predictable IP address for the network that must be in the allocation range defined for the network in the NetConfig CR.

    • ansibleVars - Node-specific Ansible variables that customize the node.

      Note
      • Nodes defined within the nodes section can configure the same Ansible variables that are configured in the nodeTemplate section. Where an Ansible variable is configured for both a specific node and within the nodeTemplate section, the node-specific values override those from the nodeTemplate section.
      • You do not need to replicate all the nodeTemplate Ansible variables for a node to override the default and set some node-specific values. You only need to configure the Ansible variables you want to override for the node.
      • When you define the networkData Secret for an individual node (such as edpm-compute-0), it acts as a complete override rather than a supplemental configuration. Because node-specific configurations override the inherited default values from the nodeTemplate section, you must ensure that your node-specific networkData Secret contains the full set of required network configurations for that node, not just the unique values.
      • Many ansibleVars include edpm in the name, which stands for "External Data Plane Management".

      For information about the properties you can use to configure node attributes, see OpenStackDataPlaneNodeSet CR spec properties in the Deploying Red Hat OpenStack Services on OpenShift guide..

14. Save the openstack_preprovisioned_networker_node_set.yaml definition file.

15. Create the data plane resources:

    $ oc create --save-config -f openstack_preprovisioned_networker_node_set.yaml -n openstack

16. Verify that the data plane resources have been created by confirming that the status is SetupReady:

    $ oc wait openstackdataplanenodeset openstack-data-plane --for condition=SetupReady --timeout=10m

    When the status is SetupReady the command returns a condition met message, otherwise it returns a timeout error.

    For information about the data plane conditions and states, see Data plane conditions and states in Deploying Red Hat OpenStack Services on OpenShift.

17. Verify that the Secret resource was created for the node set:

    $ oc get secret | grep openstack-data-plane
    dataplanenodeset-openstack-data-plane Opaque 1 3m50s

18. Verify the services were created:

    $ oc get openstackdataplaneservice -n openstack
    NAME                AGE
    bootstrap           46m
    ceph-client         46m
    ceph-hci-pre        46m
    configure-network   46m
    configure-os        46m
    ...

1. Create a BareMetalHost custom resource (CR) for each bare-metal Networker node.
2. Define an OpenStackDataPlaneNodeSet CR for the Networker nodes.

Procedure

1. Create a file on your workstation named openstack_data_plane_deploy.yaml to define the OpenStackDataPlaneDeployment CR:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: data-plane-deploy
     namespace: openstack

   • name - The OpenStackDataPlaneDeployment CR name must be unique, must consist of lower case alphanumeric characters, - (hyphen) or . (period), and must start and end with an alphanumeric character. Update the name in this example to a name that reflects the node sets in the deployment.

2. Add all the OpenStackDataPlaneNodeSet CRs that you want to deploy:

   spec:
     nodeSets:
       - openstack-data-plane
       - <nodeSet_name>
       - ...
       - <nodeSet_name>

   • Replace <nodeSet_name> with the names of the OpenStackDataPlaneNodeSet CRs that you want to include in your data plane deployment.
3. Save the openstack_data_plane_deploy.yaml deployment file.

4. Deploy the data plane:

   $ oc create -f openstack_data_plane_deploy.yaml -n openstack

   You can view the Ansible logs while the deployment executes:

   $ oc get pod -l app=openstackansibleee -w
   $ oc logs -l app=openstackansibleee -f --max-log-requests 10

   If the oc logs command returns an error similar to the following error, increase the --max-log-requests value:

   error: you are attempting to follow 19 log streams, but maximum allowed concurrency is 10, use --max-log-requests to increase the limit

5. Verify that the data plane is deployed:

   $ oc get openstackdataplanedeployment -n openstack
   NAME             	STATUS   MESSAGE
   data-plane-deploy   True     Setup Complete
   
   
   $ oc get openstackdataplanenodeset -n openstack
   NAME             	STATUS   MESSAGE
   openstack-data-plane   True     NodeSet Ready

   For information about the meaning of the returned status, see Data plane conditions and states in Deploying Red Hat OpenStack Services on OpenShift

   If the status indicates that the data plane has not been deployed, then troubleshoot the deployment. For information, see Troubleshooting the data plane creation and deployment in the Deploying Red Hat OpenStack Services on OpenShift guide.

Verification

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

   $ oc rsh -n openstack openstackclient

2. Ensure that the Networking service has successfully loaded the port_forwarding and router service plug-ins:

   $ openstack extension list --network -c Name -c Alias --max-width 74 | \
   grep -i -e 'Neutron L3 Router' -i -e floating-ip-port-forwarding \
   --os-cloud <cloud_name>

   • Replace <cloud_name> with the name of the cloud on which you are running the command.

     Sample output

     A successful verification produces output similar to the following:

     | Floating IP Port Forwarding       | floating-ip-port-forwarding        |
     | Neutron L3 Router                 | router                             |

3. Exit the openstackclient pod:

   $ exit

Procedure

1. Open /etc/sysconfig/network-scripts/ifcfg-eth0 in a text editor, and update the following parameters with values appropriate for the network at your site:

   • IPADDR
   • NETMASK GATEWAY

   • DNS1 (name server)

     Here is an example:

     DEVICE=eth0
     TYPE=OVSPort
     DEVICETYPE=ovs
     OVS_BRIDGE=br-ex
     ONBOOT=yes

2. Open /etc/sysconfig/network-scripts/ifcfg-br-ex in a text editor and update the virtual bridge parameters with the IP address values that were previously allocated to eth0:

   DEVICE=br-ex
   DEVICETYPE=ovs
   TYPE=OVSBridge
   BOOTPROTO=static
   IPADDR=192.168.120.10
   NETMASK=255.255.255.0
   GATEWAY=192.168.120.1
   DNS1=192.168.120.1
   ONBOOT=yes

   You can now assign floating IP addresses to instances and make them available to the physical network.

Procedure

1. If you are using the ML2/SR-IOV mechanism driver, you must enable the qos agent extension on the Compute nodes, also referred to as the RHOSO data plane.

   For more information, see Configuring the Networking service for QoS policies for SR-IOV.

2. Add the required QoS configuration. Place the configuration in the edpm_network_config_template under ansibleVars:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: my-data-plane-node-set
   spec:
     ...
     nodeTemplate:
       ...
       ansible:
         ansibleVars:
           edpm_network_config_template: |
             ---
             OvnHardwareOffloadedQos: true
             ...

3. If you want to create DSCP marking policies, add edpm_ovn_encap_tos: '1' under ansibleVars:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: my-data-plane-node-set
   spec:
     ...
     nodeTemplate:
       ...
       ansible:
         ansibleVars:
           edpm_network_config_template: |
             ---
             OvnHardwareOffloadedQos: true
           edpm_ovn_encap_tos: 1
             ...

   When edpm_ovn_encap_tos is enabled (has a value of 1), the Networking service copies the DSCP value of the inner header to the outer header. The default is 0.

4. Save the OpenStackDataPlaneNodeSet CR definition file.

5. Apply the updated OpenStackDataPlaneNodeSet CR configuration:

   $ oc apply -f my_data_plane_node_set.yaml

6. Verify that the data plane resource has been updated:

   $ oc get openstackdataplanenodeset

   Sample output

   NAME                     STATUS MESSAGE
   my-data-plane-node-set   False  Deployment not started

7. Create a file on your workstation to define the OpenStackDataPlaneDeployment CR, for example, my_data_plane_deploy.yaml:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: my-data-plane-deploy

   Tip

   Give the definition file and the OpenStackDataPlaneDeployment CR a unique and descriptive name that indicates the purpose of the modified node set.

8. Add the OpenStackDataPlaneNodeSet CR that you modified:

   spec:
     nodeSets:
       - my-data-plane-node-set

9. Save the OpenStackDataPlaneDeployment CR deployment file.

10. Deploy the modified OpenStackDataPlaneNodeSet CR:

    $ oc create -f my_data_plane_deploy.yaml -n openstack

    You can view the Ansible logs while the deployment executes:

    $ oc get pod -l app=openstackansibleee -n openstack -w
    
    $ oc logs -l app=openstackansibleee -n openstack -f \
    --max-log-requests 10

11. Verify that the modified OpenStackDataPlaneNodeSet CR is deployed:

    Example

    $ oc get openstackdataplanedeployment -n openstack

    Sample output

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     Setup Complete

12. Repeat the oc get command until you see the NodeSet Ready message:

    Example

    $ oc get openstackdataplanenodeset -n openstack

    Sample output

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     NodeSet Ready

    For information on the meaning of the returned status, see Data plane conditions and states in the Deploying Red Hat OpenStack Services on OpenShift guide.

Procedure

1. Open the OpenStackDataPlaneNodeSet CR definition file for the node set you want to update, for example, my_data_plane_node_set.yaml.

2. Add the required QoS configuration, NeutronSriovAgentExtensions: "qos".

   Place the configuration in the edpm_network_config_template under ansibleVars:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneNodeSet
   metadata:
     name: my-data-plane-node-set
   spec:
     ...
     nodeTemplate:
       ...
       ansible:
         ansibleVars:
           edpm_network_config_template: |
             ---
             NeutronSriovAgentExtensions: "qos"
             ...

3. Save the OpenStackDataPlaneNodeSet CR definition file.

4. Apply the updated OpenStackDataPlaneNodeSet CR configuration:

   $ oc apply -f my_data_plane_node_set.yaml

5. Verify that the data plane resource has been updated:

   $ oc get openstackdataplanenodeset

   Sample output

   NAME                     STATUS MESSAGE
   my-data-plane-node-set   False  Deployment not started

6. Create a file on your workstation to define the OpenStackDataPlaneDeployment CR, for example, my_data_plane_deploy.yaml:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneDeployment
   metadata:
     name: my-data-plane-deploy

   Tip

   Give the definition file and the OpenStackDataPlaneDeployment CR a unique and descriptive name that indicates the purpose of the modified node set.

7. Add the OpenStackDataPlaneNodeSet CR that you modified:

   spec:
     nodeSets:
       - my-data-plane-node-set

8. Save the OpenStackDataPlaneDeployment CR deployment file.

9. Deploy the modified OpenStackDataPlaneNodeSet CR:

   $ oc create -f my_data_plane_deploy.yaml -n openstack

   You can view the Ansible logs while the deployment executes:

   $ oc get pod -l app=openstackansibleee -n openstack -w
   
   $ oc logs -l app=openstackansibleee -n openstack -f \
   --max-log-requests 10

10. Verify that the modified OpenStackDataPlaneNodeSet CR is deployed:

    Example

    $ oc get openstackdataplanedeployment -n openstack

    Sample output

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     Setup Complete

11. Repeat the oc get command until you see the NodeSet Ready message:

    Example

    $ oc get openstackdataplanenodeset -n openstack

    Sample output

    NAME                     STATUS   MESSAGE
    my-data-plane-node-set   True     NodeSet Ready

    For information on the meaning of the returned status, see Data plane conditions and states in the Deploying Red Hat OpenStack Services on OpenShift guide.

1. Obtain the UUID for the NIC switch agent:

   $ openstack network agent list

2. With the neutron-sriov-nic-agent UUID, run the following command:

   $ openstack network agent show <uuid>

   Example

   $ openstack network agent show 8676ccb3-1de0-4ca6-8fb7-b814015d9e5f \
   --max-width 70

   Sample output

   You should see an agent object with a field called configuration. When the qos extension is loaded, the extensions field should contain qos in its list.

   -------------------------------------------------------------------+
   | Field             | Value                                          |
   -------------------------------------------------------------------+
   | admin_state_up    | UP                                             |
   | agent_type        | NIC Switch agent                               |
   | alive             | :-)                                            |
   | availability_zone | None                                           |
   | binary            | neutron-sriov-nic-agent                        |
   | configuration     | {device_mappings: {}, devices: 0, extensi | | | ons: [qos], resource_provider_bandwidths: |
   |                   | {}, resource_provider_hypervisors: {}, reso | | | urce_provider_inventory_defaults: {allocatio | | | n_ratio: 1.0, min_unit: 1, step_size: 1,  |
   |                   | reserved: 0}}                                |
   | created_at        | 2024-08-08 08:22:57                            |
   | description       | None                                           |
   | ha_state          | None                                           |
   | host              | edpm-compute-0.ctlplane.example.com            |
   | id                | 8676ccb3-1de0-4ca6-8fb7-b814015d9e5f           |
   | last_heartbeat_at | 2024-08-08 08:24:27                            |
   | resources_synced  | None                                           |
   | started_at        | 2024-08-08 08:22:57                            |
   | topic             | N/A                                            |
   -------------------------------------------------------------------+

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. View the list of available networks:

   $ openstack network list

   +--------------------------------------+-------------+-------------------------------------------------------+
   | id                                   | name        | subnets                                               |
   +--------------------------------------+-------------+-------------------------------------------------------+
   | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 | web-servers | 20512ffe-ad56-4bb4-b064-2cb18fecc923 192.168.200.0/24 |
   | bcc16b34-e33e-445b-9fde-dd491817a48a | private     | 7fe4a05a-4b81-4a59-8c47-82c965b0e050 10.0.0.0/24      |
   | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 | public      | 2318dc3b-cff0-43fc-9489-7d4cf48aaab9 172.24.4.224/28  |
   +--------------------------------------+-------------+-------------------------------------------------------+

3. View the list of projects:

   $ openstack project list

   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
   | 519e6344f82e4c079c8e2eabb690023b | services |
   | 80bf5732752a41128e612fe615c886c6 | demo     |
   | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
   +----------------------------------+----------+

4. Create a RBAC entry for the web-servers network that grants access to the auditors project (4b0b98f8c6c040f38ba4f7146e8680f5):

   $ openstack network rbac create --type network --target-project 4b0b98f8c6c040f38ba4f7146e8680f5 --action access_as_shared web-servers

   Sample output

   +----------------+--------------------------------------+
   | Field          | Value                                |
   +----------------+--------------------------------------+
   | action         | access_as_shared                     |
   | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
   | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | object_type    | network                              |
   | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
   | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
   +----------------+--------------------------------------+

   As a result, users in the auditors project can connect instances to the web-servers network.

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Run the openstack network rbac list command to retrieve the ID of your existing role-based access control (RBAC) policies:

   $ openstack network rbac list

   Sample output

   +--------------------------------------+-------------+--------------------------------------+
   | id                                   | object_type | object_id                            |
   +--------------------------------------+-------------+--------------------------------------+
   | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
   +--------------------------------------+-------------+--------------------------------------+

3. Run the openstack network rbac-show command to view the details of a specific RBAC entry:

   $ openstack network rbac show 314004d0-2261-4d5e-bda7-0181fcf40709

   Sample output

   +----------------+--------------------------------------+
   | Field          | Value                                |
   +----------------+--------------------------------------+
   | action         | access_as_shared                     |
   | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
   | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | object_type    | network                              |
   | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
   | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
   +----------------+--------------------------------------+

Procedure

1. Confirm that the system OS_CLOUD variable is set for your cloud:

   $ echo $OS_CLOUD
   my_cloud

   Reset the variable if necessary:

   $ export OS_CLOUD=my_other_cloud

   As an alternative, you can specify the cloud name by adding the --os-cloud <cloud_name> option each time you run an openstack command.

2. Run the openstack network rbac list command to retrieve the ID of your existing role-based access control (RBAC) policies:

   # openstack network rbac list
   +--------------------------------------+-------------+--------------------------------------+
   | id                                   | object_type | object_id                            |
   +--------------------------------------+-------------+--------------------------------------+
   | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
   +--------------------------------------+-------------+--------------------------------------+

3. Run the openstack network rbac delete command to delete the RBAC, using the ID of the RBAC that you want to delete:

   # openstack network rbac delete 314004d0-2261-4d5e-bda7-0181fcf40709
   Deleted rbac_policy: 314004d0-2261-4d5e-bda7-0181fcf40709

Procedure

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

   $ oc rsh -n openstack openstackclient

2. Create a new RBAC policy using the --action access_as_external option:

   $ openstack network rbac create --type network --target-project c717f263785d4679b16a122516247deb --action access_as_external web-servers

   Sample output

   Created a new rbac_policy:

   +----------------+--------------------------------------+
   | Field          | Value                                |
   +----------------+--------------------------------------+
   | action         | access_as_external                   |
   | id             | ddef112a-c092-4ac1-8914-c714a3d3ba08 |
   | object_id      | 6e437ff0-d20f-4483-b627-c3749399bdca |
   | object_type    | network                              |
   | target_project | c717f263785d4679b16a122516247deb     |
   | project_id     | c717f263785d4679b16a122516247deb     |
   +----------------+--------------------------------------+

   As a result, users in the engineering project are able to view the network or connect instances to it:

   $ openstack network list

   +--------------------------------------+-------------+------------------------------------------------------+
   | id                                   | name        | subnets                                              |
   +--------------------------------------+-------------+------------------------------------------------------+
   | 6e437ff0-d20f-4483-b627-c3749399bdca | web-servers | fa273245-1eff-4830-b40c-57eaeac9b904 192.168.10.0/24 |
   +--------------------------------------+-------------+------------------------------------------------------+

3. Exit the openstackclient pod:

   $ exit

Procedure

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

   $ oc rsh -n openstack openstackclient

2. Obtain the names or IDs of the project that contains the security group and the target project.

   $ openstack project list

3. Obtain the name or ID of the security group that you want to share between RHOSO projects.

   $ openstack security group list

4. Using the identifiers from the previous steps, create an RBAC policy using the openstack network rbac create command.

   In this example, the ID of the target project is 32016615de5d43bb88de99e7f2e26a1e. The ID of the security group is 5ba835b7-22b0-4be6-bdbe-e0722d1b5f24:

   Example

   $ openstack network rbac create --target-project \
   32016615de5d43bb88de99e7f2e26a1e --action access_as_shared \
   --type security_group 5ba835b7-22b0-4be6-bdbe-e0722d1b5f24

   --target-project

   specifies the project that requires access to the security group.

   Tip

   You can share data between all projects by using the --target-all-projects argument instead of --target-project <target_project>. By default, only the admin user has this privilege.

   --action access_as_shared

   specifies what the project is allowed to do.

   --type

   indicates that the target object is a security group.

   5ba835b7-22b0-4be6-bdbe-e0722d1b5f24

   is the ID of the particular security group which is being granted access to.

   The target project is able to access the security group when running the OpenStack Client security group commands, in addition to being able to bind to its ports. No other users (other than administrators and the owner) are able to access the security group.

   Tip

   To remove access for the target project, delete the RBAC policy that allows it using the openstack network rbac delete command.

5. Exit the openstackclient pod:

   $ exit

Verification

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

   $ oc rsh -n openstack openstackclient

2. Confirm that the Networking service has successfully loaded the dns_domain_ports ML2 extension driver:

   $ openstack extension list --network --max-width 75 | \
   grep dns-domain-ports --os-cloud <cloud_name>

   • Replace <cloud_name> with the name of the cloud on which you are running the command.

     Sample output

     A successful verification produces output similar to the following:

     | dns_domain for ports
     | dns-domain-ports    | Allows the DNS domain to be specified for a network
     port.

3. Create a new port (new_port) on a network (public). Assign a DNS name (my_port) to the port.

   Example

   $ openstack port create --network public --dns-name my_port new_port

4. Display the details for your port (new_port).

   Example

   $ openstack port show -c dns_assignment -c dns_domain -c dns_name -c name new_port

   Sample output

   +-------------------------+----------------------------------------------+
   | Field                   | Value                                        |
   +-------------------------+----------------------------------------------+
   | dns_assignment          | fqdn='my_port.example.com',                  |
   |                         | hostname='my_port',                          |
   |                         | ip_address='10.65.176.113'                   |
   | dns_domain              | example.com                                  |
   | dns_name                | my_port                                      |
   | name                    | new_port                                     |
   +-------------------------+----------------------------------------------+

   Under dns_assignment, the fully qualified domain name (fqdn) value for the port contains a concatenation of the DNS name (my_port) and the domain name (example.com) that you set earlier with NeutronDnsDomain.

5. Create a new VM instance (my_vm) using the port (new_port) that you just created.

   Example

   $ openstack server create --image rhel --flavor m1.small --port new_port my_vm

6. Display the details for your port (new_port).

   Example

   $ openstack port show -c dns_assignment -c dns_domain -c dns_name -c name new_port

   Sample output

   +
   ----
   +-------------------------+----------------------------------------------+
   | Field                   | Value                                        |
   +-------------------------+----------------------------------------------+
   | dns_assignment          | fqdn='my_vm.example.com',                    |
   |                         | hostname='my_vm',                            |
   |                         | ip_address='10.65.176.113'                   |
   | dns_domain              | example.com                                  |
   | dns_name                | my_vm                                        |
   | name                    | new_port                                     |
   +-------------------------+----------------------------------------------+
   ----

   + Note that the Compute service changes the dns_name attribute from its original value (my_port) to the name of the instance with which the port is associated (my_vm).

7. Exit the openstackclient pod:

   $ exit

Verification

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

   $ oc rsh -n openstack openstackclient

2. Confirm that the Networking service has successfully loaded the port_numa_affinity_policy ML2 extension driver:

   $ openstack extension list --network --max-width 74 | \
   grep port-numa-affinity-policy --os-cloud <cloud_name>

   • Replace <cloud_name> with the name of the cloud on which you are running the command.

     Sample output

     A successful verification produces output similar to the following:

     | Port NUMA affinity policy
     | port-numa-affinity-policy               | Expose the port NUMA affinity
     policy

3. Create a new port.

   When you create a port, use one of the following options to specify the NUMA affinity policy to apply to the port:

   • --numa-policy-required - NUMA affinity policy required to schedule this port.
   • --numa-policy-preferred - NUMA affinity policy preferred to schedule this port.

   • --numa-policy-legacy - NUMA affinity policy using legacy mode to schedule this port.

     Example

     $ openstack port create --network public \
       --numa-policy-legacy  myNUMAAffinityPort

4. Display the details for your port.

   Example

   $ openstack port show myNUMAAffinityPort -c numa_affinity_policy

   Sample output

   When the extension is loaded, the Value column should read, legacy, preferred or required. If the extension has failed to load, Value reads None:

   +----------------------+--------+
   | Field                | Value  |
   +----------------------+--------+
   | numa_affinity_policy | legacy |
   +----------------------+--------+

5. Exit the openstackclient pod:

   $ exit

1. Create a ConfigMap custom resource (CR) to configure the nodes.
2. Create a custom service for the feature that runs the playbook for the service.
3. Include the ConfigMap CR in the custom service.

Procedure

1. Create a ConfigMap CR that defines a new configuration for metadata rate limiting, and save it to a YAML file on your workstation, for example, neutron-metadata-rate-limit.yaml.

   Note

   Do not use the name of the default configuration file, because it would override the infrastructure configuration, such as the transport_url.

   Set values for the following rate limiting parameters:

   rate_limit_enabled

   enables you to limit the rate of metadata requests. The default value is false. Set the value to true to enable metadata rate limiting.

   ip_versions

   the IP version, 4, used for metadata IP addresses on which you want to control query rates. RHOSP does not yet support metadata rate limiting for IPv6 networks.

   base_window_duration

   the time span, in seconds, during which query requests are limited. The default value is 10 seconds.

   base_query_rate_limit

   the maximum number of requests allowed during the base_window_duration. The default value is 10 requests.

   burst_window_duration

   the time span, in seconds, that a request rate higher than the base_window_duration is allowed. The default value is 10 seconds.

   burst_query_rate_limit

   the maximum number of requests allowed during the burst_window_duration. The default value is 10 requests.

   Example

   In this example, the Networking service is configured for a base time and rate that allows instances to query the IPv4 metadata service IP address 6 times over a 60 second period. The Networking service is also configured for a burst time and rate that allows a higher rate of 2 queries during shorter periods of 10 seconds each:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: neutron-metadata-rate-limit
   data:
      20-neutron-metadata-rate.conf: |
        [metadata_rate_limiting]
        rate_limit_enabled = True
        ip_versions = 4
        base_window_duration = 60
        base_query_rate_limit = 6
        burst_window_duration = 10
        burst_query_rate_limit = 2
        ...

2. Create the ConfigMap object by using the ConfigMap CR file.

   Example

   $ oc create -f neutron-metadata-rate-limit.yaml -n openstack

3. Create an OpenStackDataPlaneService CR that defines the metadata rate limit custom service, and save it to a YAML file on your workstation, for example neutron-metadata-rate-limit-service.yaml:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: neutron-metadata-rate-limit

4. Add the ConfigMap CRs to the custom service, and specify the Secret CR for the cell that the node set that runs this service connects to:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: neutron-metadata-rate-limit
   spec:
     dataSources:
       - configMapRef:
           name: neutron-metadata-rate-limit
       - secretRef:
           name: neutron-ovn-metadata-agent-neutron-config
       - secretRef:
           name: nova-metadata-neutron-config
       - configMapRef:
           name: neutron-metadata-rate-limit
     tlsCerts:
       default:
         contents:
         - dnsnames
         - ips
         networks:
         - ctlplane
         issuer: osp-rootca-issuer-ovn
         keyUsages:
           - digital signature
           - key encipherment
           - client auth
     caCerts: combined-ca-bundle
     containerImageFields:
     - EdpmNeutronMetadataAgentImage

5. Specify the Ansible commands to create the custom service, by referencing an Ansible playbook or by including the Ansible play in the playbookContents field:

   apiVersion: dataplane.openstack.org/v1beta1
   kind: OpenStackDataPlaneService
   metadata:
     name: neutron-metadata-rate-limit
   spec:
     playbook: osp.edpm.neutron_metadata
     dataSources:
       - configMapRef:
           name: neutron-metadata-rate-limit
       - secretRef:
           name: neutron-ovn-metadata-agent-neutron-config
       - secretRef:
           name: nova-metadata-neutron-config
     tlsCerts:
       default:
         contents:
         - dnsnames
         - ips
         networks:
         - ctlplane
         issuer: osp-rootca-issuer-ovn
         keyUsages:
           - digital signature
           - key encipherment
           - client auth
     caCerts: combined-ca-bundle
     containerImageFields:
     - EdpmNeutronMetadataAgentImage

6. Create the metadata-rate-limit service:

   $ oc apply -f neutron-metadata-rate-limit -n openstack

Procedure

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

2. Add the following configuration to the neutron service configuration:

   spec:
       neutron:
           template:
               customServiceConfig: |
                  [ovn]
                  localnet_learn_fdb = true
                  fdb_age_threshold = 300
                  [ovn_nb_global]
                  fdb_removal_limit = 50

   • localnet_learn_fdb - Enables FDB learning by allowing the localnet ports that are created for each provider network to learn the MAC addresses and store them in the FDB SB table.
   • fdb_age_threshold - Sets the maximum time (seconds) that the learned MACs stay in the FDB table, and prevents this table from growing indefinitely.

   • fdb_removal_limit - Limits the number of FDB table entries that can be removed in a single transaction by the aging function.

     Important

     If you disable port security on a provider network in an environment, you must set related forwarding database (FDB) learning and aging parameters.

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

   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.