OpenStack Plugin RHOSP 17.1 Installation#

This guide provides step-by-step instructions for installing the EDA Connect OpenStack plugin on Red Hat OpenStack Platform (RHOSP) 17.1 using the OpenStack Director (TripleO).

Warning

Before proceeding with this installation method, ensure you have completed all the prerequisites and preparation steps described in the OpenStack Plugin Installation guide.

Prerequisites#

All prerequisites from the OpenStack Plugin Installation guide must be met
EDA Kubernetes preparation steps (Service Account and Token) must be completed
Red Hat OpenStack Platform Director (undercloud) is installed and operational
Refer to the Red Hat OpenStack Platform Director Installation Guide for details on setting up the undercloud and overcloud

Overview#

The installation process involves the following main steps:

Prepare custom container images that include the Nokia EDA Connect plugin
Configure Neutron with the EDA Connect mechanism driver
Deploy or update the overcloud with the EDA Connect integration
Configure LLDP on all compute and controller nodes for topology discovery

Installation Steps#

Step 1: Get Container Registry Credentials#

The EDA Connect OpenStack Plugin images are hosted on registry.connect.redhat.com/nokia-ni requiring authentication. You will need credentials to pull the Nokia-published container images for:

neutron-server
neutron-openvswitch-agent

Getting the container registry credentials

Contact your Red Hat representative to obtain the credentials for accessing the Nokia container images in the Red Hat Container Catalog.

The credentials will be in the format of a username (or service key) and password that need to be configured in the ContainerImageRegistryCredentials section during OpenStack deployment.

Step 2: Prepare Container Images#

The Nokia EDA Connect OpenStack plugin provides customized container images for neutron-server and neutron-openvswitch-agent that include the ML2 mechanism driver.

Create a container preparation parameters file to use the Nokia-published images:

YAML ResourceExample file

parameter_defaults:
  ContainerImagePrepare:
    - push_destination: true
      set:
        ceph_alertmanager_image: ose-prometheus-alertmanager
        ceph_alertmanager_namespace: registry.redhat.io/openshift4
        ceph_alertmanager_tag: v4.12
        ceph_grafana_image: rhceph-6-dashboard-rhel9
        ceph_grafana_namespace: registry.redhat.io/rhceph
        ceph_grafana_tag: latest
        ceph_image: rhceph-6-rhel9
        ceph_namespace: registry.redhat.io/rhceph
        ceph_node_exporter_image: ose-prometheus-node-exporter
        ceph_node_exporter_namespace: registry.redhat.io/openshift4
        ceph_node_exporter_tag: v4.12
        ceph_prometheus_image: ose-prometheus
        ceph_prometheus_namespace: registry.redhat.io/openshift4
        ceph_prometheus_tag: v4.12
        ceph_tag: latest
        name_prefix: openstack-
        name_suffix: ''
        namespace: registry.redhat.io/rhosp-rhel9
        neutron_driver: ovn
        rhel_containers: False
        tag: 17.1
      excludes:
        - neutron-server
        - neutron-openvswitch-agent
    - push_destination: true
      set:
        name_prefix: rhosp17-1-openstack-
        name_suffix: ''
        namespace: registry.connect.redhat.com/nokia-ni
        neutron_driver: null
        rhel_containers: false
        tag: '17.1'
      includes:
        - neutron-server
        - neutron-openvswitch-agent
      tag_from_label: '{version}-{release}'
  ContainerImageRegistryLogin: true
  ContainerImageRegistryCredentials:
    registry.connect.redhat.com:
      <USERNAME>|<SERVICE_KEY>: "<PASSWORD>"

Create the file at /home/stack/templates/container-prepare-parameters.yaml and update the credentials section with your Nokia-provided credentials:

cat > /home/stack/templates/container-prepare-parameters.yaml <<'EOF'
parameter_defaults:
  ContainerImagePrepare:
    - push_destination: true
      set:
        ceph_alertmanager_image: ose-prometheus-alertmanager
        ceph_alertmanager_namespace: registry.redhat.io/openshift4
        ceph_alertmanager_tag: v4.12
        ceph_grafana_image: rhceph-6-dashboard-rhel9
        ceph_grafana_namespace: registry.redhat.io/rhceph
        ceph_grafana_tag: latest
        ceph_image: rhceph-6-rhel9
        ceph_namespace: registry.redhat.io/rhceph
        ceph_node_exporter_image: ose-prometheus-node-exporter
        ceph_node_exporter_namespace: registry.redhat.io/openshift4
        ceph_node_exporter_tag: v4.12
        ceph_prometheus_image: ose-prometheus
        ceph_prometheus_namespace: registry.redhat.io/openshift4
        ceph_prometheus_tag: v4.12
        ceph_tag: latest
        name_prefix: openstack-
        name_suffix: ''
        namespace: registry.redhat.io/rhosp-rhel9
        neutron_driver: ovn
        rhel_containers: False
        tag: 17.1
      excludes:
        - neutron-server
        - neutron-openvswitch-agent
    - push_destination: true
      set:
        name_prefix: rhosp17-1-openstack-
        name_suffix: ''
        namespace: registry.connect.redhat.com/nokia-ni
        neutron_driver: null
        rhel_containers: false
        tag: '17.1'
      includes:
        - neutron-server
        - neutron-openvswitch-agent
      tag_from_label: '{version}-{release}'
  ContainerImageRegistryLogin: true
  ContainerImageRegistryCredentials:
    registry.connect.redhat.com:
      <USERNAME>|<SERVICE_KEY>: "<PASSWORD>"


EOF

Default values of the container preparation parameters file

The values provided here are only examples. The example is based on the default RHOSP 17.1 template. If you have a customized deployment, ensure to adjust the values accordingly.

Container Registry Credentials

Replace <USERNAME>|<SERVICE_KEY> and <PASSWORD> with the credentials provided by Red Hat for accessing the container registry. See the Get Container Registry Credentials section for more information.

Run the container image prepare command to generate the image list:

openstack tripleo container image prepare \
    -e /home/stack/templates/container-prepare-parameters.yaml \
    --output-env-file /home/stack/templates/overcloud-images.yaml

Step 3: Configure EDA CA Certificate (If required)#

If your EDA Kubernetes cluster uses a self-signed certificate, you must inject the certificate authority into the overcloud image.

Create a file at /home/stack/templates/inject-trust-anchor.yaml:

YAML ResourceExample file

parameter_defaults:
  # Map containing the CA certs and information needed for deploying them.
  # Type: json
  CAMap:
    eda.crt:
      content: |
        -----BEGIN CERTIFICATE-----
        <EDA_CA_CERTIFICATE_CONTENT>
        -----END CERTIFICATE-----

cat > /home/stack/templates/inject-trust-anchor.yaml <<EOF
parameter_defaults:
  # Map containing the CA certs and information needed for deploying them.
  # Type: json
  CAMap:
    eda.crt:
      content: |
        -----BEGIN CERTIFICATE-----
        <EDA_CA_CERTIFICATE_CONTENT>
        -----END CERTIFICATE-----


EOF

Replace <EDA_CA_CERTIFICATE_CONTENT> with the CA certificate content obtained earlier using:

kubectl get secrets/openstack-plugin -n eda-system -o 'template={{index .data "ca.crt"}}' | base64 --decode

Official CA certificates

If the EDA Kubernetes cluster uses certificates signed by a well-known certificate authority that is already trusted by the overcloud nodes, you can skip this step and omit the ca_cert_path parameter from the Neutron configuration.

Step 4: Configure Neutron for EDA Connect#

Create an environment file at /home/stack/templates/neutron-eda-connect-config.yaml with the EDA Connect plugin configuration:

YAML ResourceExample file

parameter_defaults:
  ControllerExtraConfig:
    neutron::config::plugin_ml2_config:
      DEFAULT/nic_mapping_provisioning:
        value: 'True'
      ml2_eda_connect/plugin_name:
        value: '<OPENSTACK_PLUGIN_NAME>'
      ml2_eda_connect/api_host:
        value: 'https://api.eda.example.com:6443'
      ml2_eda_connect/api_namespace:
        value: 'default'
      ml2_eda_connect/api_token:
        value: '<SERVICE_ACCOUNT_TOKEN>'
      ml2_eda_connect/ca_cert_path:
        value: '/etc/pki/ca-trust/source/anchors/eda.crt.pem'
  NeutronFirewallDriver: openvswitch
  NeutronOVSFirewallDriver: openvswitch
  NeutronServicePlugins: router,segments,trunk,qos,network_segment_range,port_forwarding,conntrack_helper,nic_mapping,log
  NeutronTypeDrivers: vxlan,vlan,flat,gre
  NeutronNetworkType: vlan,vxlan
  NeutronMechanismDrivers: eda_connect,openvswitch,sriovnicswitch,l2population
  NeutronAgentExtensions: nic-mapping,qos
  NeutronPluginExtensions: eda_network,qos,port_security,tag_ports_during_bulk_creation,dns_domain_keywords

cat > /home/stack/templates/neutron-eda-connect-config.yaml <<'EOF'
parameter_defaults:
  ControllerExtraConfig:
    neutron::config::plugin_ml2_config:
      DEFAULT/nic_mapping_provisioning:
        value: 'True'
      ml2_eda_connect/plugin_name:
        value: '<OPENSTACK_PLUGIN_NAME>'
      ml2_eda_connect/api_host:
        value: 'https://api.eda.example.com:6443'
      ml2_eda_connect/api_namespace:
        value: 'default'
      ml2_eda_connect/api_token:
        value: '<SERVICE_ACCOUNT_TOKEN>'
      ml2_eda_connect/ca_cert_path:
        value: '/etc/pki/ca-trust/source/anchors/eda.crt.pem'
  NeutronFirewallDriver: openvswitch
  NeutronOVSFirewallDriver: openvswitch
  NeutronServicePlugins: router,segments,trunk,qos,network_segment_range,port_forwarding,conntrack_helper,nic_mapping,log
  NeutronTypeDrivers: vxlan,vlan,flat,gre
  NeutronNetworkType: vlan,vxlan
  NeutronMechanismDrivers: eda_connect,openvswitch,sriovnicswitch,l2population
  NeutronAgentExtensions: nic-mapping,qos
  NeutronPluginExtensions: eda_network,qos,port_security,tag_ports_during_bulk_creation,dns_domain_keywords


EOF

Update the following parameters in the file:

ml2_eda_connect/plugin_name: A unique name for this OpenStack deployment within EDA (e.g., openstack-plugin or rhosp-prod)

Plugin Name Requirements

The plugin name must comply with the regex check of '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]' and can only contain alphanumerical characters and ., _ and -. It must start with an alphanumerical character, and have a length of 63 characters or fewer.

ml2_eda_connect/api_host: The API endpoint of the EDA Kubernetes cluster (e.g., https://api.eda.example.com:6443)
ml2_eda_connect/api_namespace: The namespace in EDA where the fabric is configured (e.g., default or your custom namespace)
ml2_eda_connect/api_token: The bearer token obtained from the service account token secret in the Create a Service Account Token section
ml2_eda_connect/ca_cert_path: Path to the CA certificate file (use /etc/pki/ca-trust/source/anchors/eda.crt.pem if injecting the certificate, or omit if using a trusted CA)

Additional Configuration Parameters explained

NIC Mapping Provisioning: Enables the automatic discovery of the physical NIC to Neutron network topology
Mechanism Drivers: The eda_connect driver must be listed to enable fabric orchestration
Service Plugins: The nic_mapping plugin is required for topology discovery
Plugin Extensions: The eda_network extension enables EDA-managed networking features

Example values

The values provided here are only examples. The example is based on the default RHOSP 17.1 template. If you have a customized deployment, ensure to adjust the values accordingly.

Step 5: Configure NIC Bonding (Optional)#

If your deployment uses bonded interfaces for high availability or increased bandwidth, configure the appropriate bond type in your NIC configuration templates.

Linux Bonds (for VIRTIO and SR-IOV)#

For active-backup mode Linux bonds an example configuration is as follows:

- type: linux_bond
  name: bond1
  bonding_options: "mode=active-backup miimon=100"
  use_dhcp: false
  mtu: 9000
  members:
    - type: interface
      name: nic2
      primary: true
      mtu: 9000
    - type: interface
      name: nic3
      mtu: 9000

Supported bonding modes:

mode=active-backup: Active/standby failover
mode=802.3ad: LACP-based link aggregation

Note

For active-backup mode, no LAG configuration is required in EDA. For 802.3ad mode, configure a LAG with LACP settings in the EDA Interfaces.

OVS DPDK Bonds#

For balance-tcp mode with LACP an example is as follows:

- type: ovs_dpdk_bond
  name: bond1
  mtu: 9000
  ovs_options: "bond_mode=balance-tcp lacp=active other-config:lacp-fallback-ab=true other_config:lacp-time=fast"
  members:
    - type: ovs_dpdk_port
      name: ens3f0np0
      driver: mlx5_core
      members:
        - type: interface
          name: ens3f0np0
    - type: ovs_dpdk_port
      name: ens3f1np1
      driver: mlx5_core
      members:
        - type: interface
          name: ens3f1np1

Supported bonding modes:

bond_mode=active-backup: Active/standby failover
bond_mode=balance-tcp with lacp=active: LACP-based load balancing

Note

For balance-tcp mode with LACP, configure a LAG with LACP settings in the EDA Interfaces.

Example Bond Configuration

Make sure to adapt the above examples to your specific deployment and bonding requirements.

Step 6: Deploy or Update the Overcloud#

Add the environment files created above to your openstack overcloud deploy command:

openstack overcloud deploy \
    --log-file overcloud_deployment.log \
    --templates /usr/share/openstack-tripleo-heat-templates/ \
    --stack overcloud \
    -n /home/stack/templates/network_data.yaml \
    -r /home/stack/templates/roles_data.yaml \
    -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
    -e /home/stack/templates/overcloud-networks-deployed.yaml \
    -e /home/stack/templates/overcloud-vip-deployed.yaml \
    -e /home/stack/templates/overcloud-images.yaml \
    -e /home/stack/templates/neutron-eda-connect-config.yaml \
    -e /home/stack/templates/inject-trust-anchor.yaml

Environment file order

The order of environment files matters. Ensure that:

overcloud-images.yaml is included to use the Nokia container images
neutron-eda-connect-config.yaml comes after any base Neutron configuration
inject-trust-anchor.yaml is included if using self-signed certificates

Updating an existing deployment

If updating an existing overcloud deployment, you can use the openstack overcloud update command instead. Make sure to include all the environment files from the original deployment plus the new EDA Connect configuration files.

Step 7: Configure LLDP on Overcloud Nodes#

After the overcloud deployment completes, LLDP must be enabled on all data plane interfaces of the controllers and computes for topology discovery.

Create an Ansible playbook file at /home/stack/post-overcloud-lldp.yaml:

YAML ResourceExample file

---
- hosts: neutron_ovs_agent,neutron_ovs_dpdk_agent
  gather_facts: no
  become: true
  tasks:
    - name: Make sure the lldpd package is installed
      package:
        name:
          - lldpd
        state: present
    - name: Make sure lldpd service is enabled/running
      service:
        name: lldpd
        state: started
        enabled: yes
    - name: Configure portID TLV value
      command: lldpcli configure lldp portidsubtype ifname
    - name: Configure lldpd interface pattern
      command: lldpcli configure system interface pattern {{ nic_pattern | default('em*,en*,p*,!en*v*,!p*v*') }}

cat > /home/stack/post-overcloud-lldp.yaml <<'EOF'
---
- hosts: neutron_ovs_agent,neutron_ovs_dpdk_agent
  gather_facts: no
  become: true
  tasks:
    - name: Make sure the lldpd package is installed
      package:
        name:
          - lldpd
        state: present
    - name: Make sure lldpd service is enabled/running
      service:
        name: lldpd
        state: started
        enabled: yes
    - name: Configure portID TLV value
      command: lldpcli configure lldp portidsubtype ifname
    - name: Configure lldpd interface pattern
      command: lldpcli configure system interface pattern {{ nic_pattern | default('em*,en*,p*,!en*v*,!p*v*') }}


EOF

Run the playbook against the overcloud inventory:

ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook -v \
    -i ~/overcloud-deploy/overcloud/config-download/overcloud/tripleo-ansible-inventory.yaml \
    /home/stack/post-overcloud-lldp.yaml

LLDP package requirements

The playbook depends on the availability of the lldpd package on overcloud nodes. Overcloud nodes must be registered to Red Hat Subscription Manager (RHSM) to install the package. Alternatively, you can modify the overcloud image to include the lldpd package before deployment.

Customizing interface patterns

The default interface pattern em*,en*,p*,!en*v*,!p*v* matches most physical interfaces while excluding virtual interfaces. You can override this by passing the nic_pattern variable to the playbook:

ansible-playbook -v -i <inventory> post-overcloud-lldp.yaml -e "nic_pattern='ens*,eno*'"

Post-Installation Configuration#

Verify LLDP is Functioning#

On one of the overcloud compute or controller nodes, verify LLDP is transmitting and receiving:

sudo lldpcli show neighbors

You should see the connected fabric switches listed as neighbors.

Verify Topology Discovery#

From the undercloud or a system with OpenStack client access, verify the NIC mapping has been discovered:

openstack eda interface mapping list

This should display the discovered mappings between physical networks and compute node interfaces.

Troubleshooting#

Neutron Server Fails to Start#

If the Neutron server container fails to start, check the logs:

sudo podman logs neutron_api

Common issues:

Invalid API token: Verify the token is correct and not expired
Cannot reach EDA API: Check network connectivity and the API host URL
Certificate validation errors: Ensure the CA certificate is correctly injected

LLDP Not Discovering Topology#

If topology discovery is not working:

Verify LLDP is running on overcloud nodes:
```
sudo systemctl status lldpd
```
Check LLDP is configured with the correct interface pattern:
```
sudo lldpcli show configuration
```
Verify the fabric switches have LLDP enabled on the interfaces connected to OpenStack nodes

Networks Not Creating BridgeDomains in EDA#

If OpenStack networks are not creating corresponding BridgeDomains in EDA:

Check the Neutron controller logs for errors:

Verify the ConnectPlugin is registered and healthy in EDA:

kubectl get connectplugins -n <eda-namespace> -o yaml

Ensure the network is created with provider-network-type vlan (the plugin only manages VLAN networks)

Updating the Bearer Token After Installation#

If you need to update the bearer token after installation:

Update the configuration file on all controller nodes at /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/ml2_conf.ini:

[ml2_eda_connect]
api_token = <new_api_token>

Restart the Neutron server container on all controllers