Integrating partner content

Red Hat OpenStack Services on OpenShift 18.0

Integrating and certifying third-party software and hardware for Red Hat OpenStack Services on OpenShift

OpenStack Documentation Team

rhos-docs@redhat.com

Abstract

This guide contains procedures for integrating and certifying third-party software and hardware in a Red Hat OpenStack Services on OpenShift environment.

Providing feedback on Red Hat documentation
Copy link

We appreciate your input on our documentation. Tell us how we can make it better.

Use the Create Issue form to provide feedback on the documentation for Red Hat OpenStack Services on OpenShift (RHOSO) or earlier releases of Red Hat OpenStack Platform (RHOSP). When you create an issue for RHOSO or RHOSP documents, the issue is recorded in the RHOSO Jira project, where you can track the progress of your feedback.

To complete the Create Issue form, ensure that you are logged in to Jira. If you do not have a Red Hat Jira account, you can create an account at https://issues.redhat.com.

Click the following link to open a Create Issue page: Create Issue
Complete the Summary and Description fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form.
Click Create.

Chapter 1. Integrating and certifying with RHOSO
Copy link

This guide describes the process for Partners to integrate Partner solutions, such as drivers (Storage, Networking) or application workloads (VNF, NFV), with Red Hat OpenStack Services on OpenShift (RHOSO), before certifying the solutions. Upon the successful integration of the Partner solution with RHOSO, Partners can then proceed with Red Hat OpenStack Certification. Red Hat OpenStack Certification is offered to Partners who want to offer their solutions for use with RHOSO in a jointly-supported customer environment. For more information about the certification process, see the Product Documentation for Red Hat Software Certification

1.1. General Certification Prerequisites
Copy link

If this is your first time certifying your solution with RHOSO, or you need a refresh on the Red Hat Partner process, you can request an orientation session with the Red Hat Technology Partner Success Desk (TPSD) of the Ecosystem Partner Management (EPM) Team. Select the "Certification" for the category and Red Hat OpenStack Platform for the product. The orientation session is to review the requirements for the certification process and answer any questions that you might have.

The following are certification prerequisites and integration points for OpenStack drivers for the Block storage service (cinder), the File storage services (manila), and the Networking service (neutron). Ensure that you review the prerequisites for any OpenStack driver or service before you progress further.

Chapter 2. integrating RHOSO storage services
Copy link

Red Hat only certifies Red Hat OpenStack Services on OpenShift (RHOSO) Storage drivers that are distributed by Red Hat. Conversely, Red Hat does not certify drivers that are distributed directly by the Partner. For Red Hat to distribute a Partner’s storage driver, ensure that the following requirements are met:

Prerequisites

The driver must be present in the upstream OpenStack project, such as openstack-cinder or openstack-manila. For information on contributing upstream to OpenStack, see the OpenStack Contributor Guide and the upstream guides for OpenStack Block Storage (Cinder) or OpenStack Shared Filesystems (Manila). The Cinder project also has specific guidelines for contributing drivers that you can view here: All About Cinder Drivers.
Partners must contribute the driver patches upstream, and the patches must be accepted by the upstream community before they can be included in RHOSO. Red Hat does not accept patches or code modifications to a driver that have not been accepted by the upstream community.
The driver must be present in the RHOSO release.
- This requirement is automatically met when the driver is present in the upstream OpenStack release associated with the corresponding version of RHOSO. RHOSO 18 is based on the upstream OpenStack 2023.1 Antelope release. Storage drivers present in the upstream 2023.1 release are automatically included in RHOSO 18.
- When an upstream driver or updates to that driver is absent in the corresponding upstream release, the Partner can submit requests for Red Hat to back port upstream patches into RHOSO by creating a JIRA issue in the following project: OSPRH.

Additional integration tasks

To integrate a storage driver with RHOSO, you must perform the following actions in addition to the prerequisites:

Configuring the storage driver.
Adding software dependencies required by the driver.
Accessing extra files required by the driver.

2.1. Configuring the storage driver
Copy link

Red Hat OpenStack Services on OpenShift (RHOSO) uses OpenShift custom resource definitions (CRDs), which you deploy using an OpenStackControlPlane custom resource (CR). The OpenStackControlPlane CR includes specification templates that govern the openstack-cinder and openstack-manila service deployments, which include sections for configuring back end storage drivers. The syntax for configuring storage backends is similar to the openstack-cinder and openstack-manila syntax.

For more information on how to configure and deploy the openstack-cinder and openstack-manila storage services, see the Configuring persistent storage guide.

2.2. Adding software dependencies for the storage driver
Copy link

Red Hat OpenStack Services on OpenShift (RHOSO) openstack-cinder and openstack-manila services execute in Linux containers that are built by Red Hat. These container images include the necessary software to support a large number of drivers. However, some drivers require additional software components that are not included in the RHOSO container images. These are typically python modules that are supplied by the Partner and not available for inclusion in Red Hat’s container images. Drivers that are fully self-contained in RHOSO container images are considered "in-tree," as opposed to drivers that have external software dependencies.

Early in the integration process, Partners must determine whether their driver has an external software dependency. The following information only applies when the driver has external dependencies:

When a Partner’s driver has an external software dependency, Partners must provide a container image that adds an additional layer on top of Red Hat’s RHOSO container image.

Partner container images for RHOSO are similar to a Partner’s container images for director-based RHOSP.
The purpose of providing a Partner container image is to satisfy the external software dependencies required by the Partner’s driver. You cannot use container images to deploy a modified version of the Partner’s driver or a version of the driver that differs from the one provided by Red Hat in the underlying RHOSO container image.
Partners are responsible for generating their container images, and the image has to go through container image certification procedure before the Red Hat OpenStack certification. Details on how to certify a container image are provided later in this guide. NOTE: Container image certification is not the same as Red Hat OpenStack certification. Container images must undergo a separate certification procedure in order to be delivered in the Red Hat Ecosystem Catalog.
After a Partner’s storage driver has passed Red Hat OpenStack Certification, the Partner is responsible for generating a certified container image for every subsequent minor update to the RHOSO release.
- For each minor RHOSO 18 update, Partners must generate an updated container image for the updated release, and publish the updated container image in the Red Hat Ecosystem Catalog.
- Container images for older RHOSO 18 minor updates must remain in the Red Hat Ecosystem Catalog. This ensures that customers that are not using the latest RHOSO release can still access the Partner’s container image that was built for their RHOSO version.

2.2.1. Building partner container images
Copy link

A Partner must provide a Red Hat certified container image if their storage driver has external software dependencies that are not supplied by Red Hat’s corresponding container image. An example is the cinder-volume service, which includes Partner drivers for many block storage back ends. When a Partner’s driver has external software dependencies, they must provide a cinder-volume container image to layer that software on top of Red Hat’s RHOSO cinder-volume container image.

Create a Containerfile for generating the container image:

The following example shows a sample Containerfile or Dockerfile for generating a cinder-volume container image that includes external software dependencies required by a Partner’s openstack-cinder driver. The example can be adapted to generate a manila-share container image that includes external software dependencies required by a Partner’s openstack-manila driver.

FROM registry.redhat.io/rhoso/openstack-cinder-volume-rhel9:18.0 

LABEL name="rhoso18/openstack-cinder-volume-partnerX-plugin" \
      maintainer="maintainer@partnerX.com" \
      vendor="PartnerX" \
      summary="RHOSO 18.0 cinder-volume PartnerX PluginY" \
      description="RHOSO 18.0 cinder-volume PartnerX PluginY" 

# Switch to root to install software dependencies
USER root

# Enable a repo to install a package 
COPY vendorX.repo /etc/yum.repos.d/vendorX.repo
RUN dnf clean all && dnf install -y vendorX-plugin

# Install a package over the network 
RUN dnf install -y http://vendorX.com/partnerX-plugin.rpm

# Install a local package 
COPY partnerX-plugin.rpm /tmp
RUN dnf install -y /tmp/partnerX-plugin.rpm && \
  rm -f /tmp/partnerX-plugin.rpm

# Install a python package from PyPI 
RUN curl -OL https://bootstrap.pypa.io/get-pip.py && \
  python3 get-pip.py --no-setuptools --no-wheel && \
  pip3 install partnerX-plugin && \
  rm -f get-pip.py

# Add required license as text file(s) in /licenses directory
# (GPL, MIT, APACHE, Partner End User Agreement, etc)
RUN mkdir /licenses
COPY licensing.txt /licenses

# Switch to cinder user
USER cinder

FROM registry.redhat.io/rhoso/openstack-cinder-volume-rhel9:18.0



LABEL name="rhoso18/openstack-cinder-volume-partnerX-plugin" \
      maintainer="maintainer@partnerX.com" \
      vendor="PartnerX" \
      summary="RHOSO 18.0 cinder-volume PartnerX PluginY" \
      description="RHOSO 18.0 cinder-volume PartnerX PluginY"



# Switch to root to install software dependencies
USER root

# Enable a repo to install a package


COPY vendorX.repo /etc/yum.repos.d/vendorX.repo
RUN dnf clean all && dnf install -y vendorX-plugin

# Install a package over the network


RUN dnf install -y http://vendorX.com/partnerX-plugin.rpm

# Install a local package


COPY partnerX-plugin.rpm /tmp
RUN dnf install -y /tmp/partnerX-plugin.rpm && \
  rm -f /tmp/partnerX-plugin.rpm

# Install a python package from PyPI


RUN curl -OL https://bootstrap.pypa.io/get-pip.py && \
  python3 get-pip.py --no-setuptools --no-wheel && \
  pip3 install partnerX-plugin && \
  rm -f get-pip.py

# Add required license as text file(s) in /licenses directory
# (GPL, MIT, APACHE, Partner End User Agreement, etc)
RUN mkdir /licenses
COPY licensing.txt /licenses

# Switch to cinder user
USER cinder

Copy to Clipboard

Toggle word wrap

1: Use the FROM clause to specify the Red Hat’s RHOSO base image, which in this example is the cinder-volume service. The 18.0 tag specifies the current latest release. To generate an image based on a specific minor release, modify the tag to specify that release, for example 18.0.1, or openstack-cinder-volume-rhel9:*18.0.1*. For RHOSO 18 GA, use the URL: registry.redhat.io/rhoso/openstack-cinder-volume-rhel9:18.0.
2: The labels in the sample Containerfile override the corresponding labels in the base image to uniquely identify the Partner’s image.
3: You can install the software dependencies by this method, or the method at 4, 5, or 6.
4: You can install the software dependencies by this method, or the method at 3, 5, or 6.
5: You can install the software dependencies by this method, or the method at 3, 4, or 6.
6: You can install the software dependencies by this method, or the method at 3, 4, or 5.

Build, tag, and upload the container image:
You can use the podman build or buildah build commands to build the container image. For more information on how Partners chose a registry and provide an access token to the registry for the certification, see the Red Hat Software Certification Workflow Guide.
Tag the image to match the corresponding RHOSO 18 base image. For example, when the base image is version 18.0.0, the Partner’s image is also tagged as version 18.0.0.
You can also use the above example procedure with the file storage service, openstack-manila. Ensure that you use the appropriate RHOSO openstack-manila-share base image in place of the openstack-cinder-volume base image.
Certify and publish the container image:
For information on how to certify the container image, see Red Hat Enterprise Linux Software Certification Policy Guide and Red Hat Software Certification Workflow Guide. You can publish container images in the Red Hat Ecosystem Catalog.

2.2.2. Maintaining partner container images and image tags
Copy link

When a Partner certifies their storage solution, and if the solution includes a container image, then the Partner is responsible for rebuilding that image every time the underlying RHOSO container image changes. This happens with each RHOSO maintenance release, but it can also happen when RHOSO container images are updated to address a CVE.

For example, if a Partner certified their solution against RHOSO 18.0.1, the Partner’s container image needs two tags:

18.0.1 to indicate the specific release.
18.0 to indicate this is the latest version associated with RHOSO 18.

Later, when Red Hat releases version 18.0.2, the Partner must rebuild their image and update the images and tags:

The tag for the new image is 18.0.2.
The older 18.0.1 image must remain in the Red Hat Ecosystem Catalog. Partners must not remove old images.
Remove the 18.0 tag from the older 18.0.1 image, and add it to the new 18.0.2 image.

2.2.3. Deploying partner container images
Copy link

With director-based Red Hat Openstack Platform (RHOSP), you can only specify a single cinder-volume container image despite the number of back ends. However, with Red Hat OpenStack Services on OpenShift (RHOSO), you can customize the container image per back end and configure a multi-storage back end within a single RHOSO deployment. You can use the OpenStackVersion CR to override the container image for any service.

In the following example, you use the OpenStackVersion CR to configure cinder-volume and manila-share back ends:

Two cinder-volume back ends named backend_x1 and backend_x2 to use the custom container image of one storage vendor (partner_x)
One cinder-volume back end named backend_y to use the custom container image of a second storage vendor (partner_y)
One manila-share back end named backend_z to use the custom container image of a third storage vendor (partner_y)

Example:

apiVersion: core.openstack.org/v1beta1
kind: OpenStackVersion
metadata:
  name: openstack
spec:
  customContainerImages:
    cinderVolumeImages:
      <backend_x1>: registry.connect.redhat.com/<partner_x>/<cinder-volume_partner_x_plugin>
      <backend_x2>: registry.connect.redhat.com/<partner_x>/<cinder-volume_partner_x_plugin>
      <backend_y>: registry.connect.redhat.com/<partner_y>/<cinder-volume_partner_y_plugin>
    manilaShareImages:
      <backend_z>: registry.connect.redhat.com/<partner_z>/<manila-share_partner_z_plugin>

apiVersion: core.openstack.org/v1beta1
kind: OpenStackVersion
metadata:
  name: openstack
spec:
  customContainerImages:
    cinderVolumeImages:
      <backend_x1>: registry.connect.redhat.com/<partner_x>/<cinder-volume_partner_x_plugin>
      <backend_x2>: registry.connect.redhat.com/<partner_x>/<cinder-volume_partner_x_plugin>
      <backend_y>: registry.connect.redhat.com/<partner_y>/<cinder-volume_partner_y_plugin>
    manilaShareImages:
      <backend_z>: registry.connect.redhat.com/<partner_z>/<manila-share_partner_z_plugin>

Copy to Clipboard

Toggle word wrap

The <backend_x1>, <backend_x2>, <backend_y>, and <backend_z> values represent the names of the storage back ends.
The <partner_x>, <partner_y>, and <partner_z> values represent the partner’s container registry namespace when the partner’s container image is registered in the Red Hat catalog.
The <cinder-volume_partner_x_plugin>, <cinder-volume_partner_y_plugin>, and <manila-share_partner_z_plugin> values represent the name of the partner’s image.

For more information about the values to use when you deploy partner container images, see the partner’s documentation.

2.3. Accessing extra files for the storage driver
Copy link

You can use the OpenStackControlPlane CRD extraMounts feature to provide files to the openstack-cinder and openstack-manila storage services, for example extra files that might be required by a Partner’s storage driver. Consider a situation where a Partner’s openstack-cinder driver requires a config.xml file that contains authentication credentials in order to access the Partner’s back end storage array. You can store the contents of the XML file in a kubernetes secret, which can be created from a YAML file:

apiVersion: v1
kind: Secret
metadata:
  name: cinder-volume-example-config 
type: Opaque
stringData:
  config.xml: | 
	<example-credentials>example</example-credentials>

apiVersion: v1
kind: Secret
metadata:
  name: cinder-volume-example-config


type: Opaque
stringData:
  config.xml: |


	<example-credentials>example</example-credentials>

Copy to Clipboard

Toggle word wrap

1: The secret name is arbitrary, but the example includes the storage service and the Partner’s name, “Example”, for clarity.
2: The name of the file required by the Example storage driver is config.xml.
3: Sample XML data.

An extraMounts entry in the cinder section of the OpenStackControlPlane CR mounts the config.xml into the cinder-volume pod associated with the cinder back end.

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderApi:
        ...
      cinderScheduler:
        ...
      cinderVolumes:
        example: 
          customServiceConfig: |
            [example]
            volume_backend_name=example
            volume_driver=cinder....ExampleDriver
          networkAttachments:
            - storage
          replicas: 1
      extraMounts: 
      - extraVol:
        - mounts:
          - name: example-config
            mountPath: /etc/cinder/config.xml 
            subPath: config.xml 
            readOnly: true
          propagation:
          - example 
          volumes:
          - name: example-config
            secret:
              secretName: cinder-volume-example-config

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  cinder:
    template:
      cinderApi:
        ...
      cinderScheduler:
        ...
      cinderVolumes:
        example:


          customServiceConfig: |
            [example]
            volume_backend_name=example
            volume_driver=cinder....ExampleDriver
          networkAttachments:
            - storage
          replicas: 1
      extraMounts:


      - extraVol:
        - mounts:
          - name: example-config
            mountPath: /etc/cinder/config.xml


            subPath: config.xml


            readOnly: true
          propagation:
          - example


          volumes:
          - name: example-config
            secret:
              secretName: cinder-volume-example-config

Copy to Clipboard

Toggle word wrap

1: This section is for the cinder-volume back end configuration for the Example driver.
2: This section is for the extraMounts configuration for the cinder section of the OpenStackControlPlane. Note that the extraMounts are not nested under the cinderVolumes section.
3: This section is for the mount point where the config.xml file appears in the cinder-volume pod.
4: This section is for the subPath to specify the config.xml filename. This is necessary to mount a single file in the /etc/cinder directory.
5: This section is for the propagation to specify that it applies to only the Example cinder-volume back end. The value matches the back end name in <1>.
6: The secretName matches the name of the secret created previously.

Chapter 3. Integrating RHOSO networking services
Copy link

Red Hat only certifies Red Hat OpenStack Services on OpenShift (RHOSO) Networking drivers that are distributed by Red Hat. Conversely, Red Hat does not certify drivers that are distributed directly by the Partner.

To integrate a Networking driver with RHOSO, you must perform the following actions:

Build a neutron-api container with the Networking driver.
Configure the Networking driver in the neutron-api component.
Configure additional software dependencies, such as agents on the External DataPlane Nodes (EDPM), that are required by the driver.
Access extra files that are required by the driver.

3.1. Configure the networking driver
Copy link

Red Hat OpenStack Services on OpenShift (RHOSO) uses OpenShift custom resource definitions (CRDs), which you deploy by using OpenStackControlPlane, OpenStackDataPlaneDeployment, and OpenStackDataPlaneNodeSet custom resources (CR). The OpenStackControlPlane CR includes specification templates that govern the openstack-neutron API service deployment, which include sections for configuring networking drivers. The OpenStackDataPlaneNodeSet CR includes specification templates that govern components that are deployed on the EDPM nodes. For information about configuring and deploying the openstack-neutron service, see the Configuring networking services guide.

3.2. Prepare neutron-api component with the new networking driver
Copy link

Red Hat OpenStack Services on OpenShift (RHOSO) openstack-neutron services execute in Linux containers that are built by Red Hat. These container images include the "in-tree” networking drivers such as ML2/OVN. You must prepare new container images to use Partner networking drivers. Partners must provide a container image that adds an additional layer on top of Red Hat’s RHOSO container image.

Partner container images for RHOSO are similar to a Partner’s container images for director-based RHOSP.
The purpose of providing a Partner container image is to provide software dependencies required by the Partner’s driver.
Partners are responsible for generating their container images, and the image has to go through the container image certification procedure before the Red Hat OpenStack certification. The container image certification is separate from Red Hat OpenStack certification and is a requirement for inclusion in the Red Hat Ecosystem Catalog.
After a Partner’s networking driver has passed Red Hat OpenStack Certification, the Partner is responsible for generating a certified container image for every subsequent minor update to the RHOSO release.
- For each minor RHOSO 18 update, Partners must generate an updated container image for the updated release, and publish the updated container image in the Red Hat Ecosystem Catalog.
- Container images for older RHOSO 18 minor updates must remain in the Red Hat Ecosystem Catalog. This ensures that customers that are not using the latest RHOSO release can still access the Partner’s container image that was built for their RHOSO version.

3.2.1. Building partner container images for networking services
Copy link

A Partner must provide a Red Hat certified container image. A neutron-server service includes “in-tree” drivers for the OVN back end and many service plugins. Partners must provide a neutron-server container image to layer networking driver software on top of the RHOSO neutron-server container image.

Note

Depending on your plug-in or driver, you might also need to deploy additional services or agents on the data plane or the control plane nodes. For the control plane you can add a new OpenShift operator using operator-sdk, and for the data plane you can add a new OpenStackDataPlaneService. You can build the OpenStackDataPlaneService service on official Neutron agent images and edpm-ansible roles. You are responsible for the stability of the interface for new custom services.

Procedure

Create a Containerfile for generating the container image: The following example shows a sample Containerfile or Dockerfile for generating a neutron-server container image that includes external software dependencies that are required by a Partner’s openstack-neutron driver. The example can be adapted to generate any other neutron-related container image that includes external software dependencies that are required by a Partner’s openstack-neutron driver.

FROM registry.redhat.io/rhoso/openstack-neutron-server-rhel9:18.0.1		

LABEL name="rhoso18/openstack-neutron-server-partnerX-plugin" \
      maintainer="maintainer@partnerX.com" \
      vendor="PartnerX" \
      summary="RHOSO 18.0 neutron-server PartnerX PluginY" \
      description="RHOSO 18.0 neutron-server PartnerX PluginY" 	

# Switch to root to install software dependencies
USER root

# Enable a repo to install a package 			
COPY vendorX.repo /etc/yum.repos.d/vendorX.repo
RUN dnf clean all && dnf install -y vendorX-plugin

# Install a package over the network 			
RUN dnf install -y http://vendorX.com/partnerX-plugin.rpm

# Install a local package 						 
COPY partnerX-plugin.rpm /tmp
RUN dnf install -y /tmp/partnerX-plugin.rpm && \
  rm -f /tmp/partnerX-plugin.rpm

# Install a python package from PyPI            
RUN curl -OL https://bootstrap.pypa.io/get-pip.py && \
  python3 get-pip.py --no-setuptools --no-wheel && \
  pip3 install partnerX-plugin && \
  rm -f get-pip.py

# Add required license as text file(s) in /licenses directory
# (GPL, MIT, APACHE, Partner End User Agreement, etc)
RUN mkdir /licenses
COPY licensing.txt /licenses

# Switch to neutron user
USER neutron

FROM registry.redhat.io/rhoso/openstack-neutron-server-rhel9:18.0.1



LABEL name="rhoso18/openstack-neutron-server-partnerX-plugin" \
      maintainer="maintainer@partnerX.com" \
      vendor="PartnerX" \
      summary="RHOSO 18.0 neutron-server PartnerX PluginY" \
      description="RHOSO 18.0 neutron-server PartnerX PluginY"



# Switch to root to install software dependencies
USER root

# Enable a repo to install a package


COPY vendorX.repo /etc/yum.repos.d/vendorX.repo
RUN dnf clean all && dnf install -y vendorX-plugin

# Install a package over the network


RUN dnf install -y http://vendorX.com/partnerX-plugin.rpm

# Install a local package


COPY partnerX-plugin.rpm /tmp
RUN dnf install -y /tmp/partnerX-plugin.rpm && \
  rm -f /tmp/partnerX-plugin.rpm

# Install a python package from PyPI


RUN curl -OL https://bootstrap.pypa.io/get-pip.py && \
  python3 get-pip.py --no-setuptools --no-wheel && \
  pip3 install partnerX-plugin && \
  rm -f get-pip.py

# Add required license as text file(s) in /licenses directory
# (GPL, MIT, APACHE, Partner End User Agreement, etc)
RUN mkdir /licenses
COPY licensing.txt /licenses

# Switch to neutron user
USER neutron

Copy to Clipboard

Toggle word wrap

1: Use the FROM clause to specify the RHOSO base image, which in this example is the neutron-server service. The 18.0.1 tag specifies the release. To generate an image based on a specific minor release, modify the tag to specify that release, for example 18.0.0, or openstack-neutron-server-rhel9:*18.0.0*. For RHOSO 18 GA, use the URL: registry.redhat.io/rhoso/openstack-neutron-server-rhel9:18.0.
2: The labels in the sample Containerfile override the corresponding labels in the base image to uniquely identify the Partner’s image.
3: You can install the software dependencies by this method, or the method at 4, 5, or 6.
4: You can install the software dependencies by this method, or the method at 3, 5, or 6.
5: You can install the software dependencies by this method, or the method at 3, 4, or 6.
6: You can install the software dependencies by this method, or the method at 3, 4, or 5.

Build, tag, and upload the container image. You can use the podman build or buildah build commands to build the container image. For more information on how Partners chose a registry and provide an access token to the registry for the certification, see the Red Hat Software Certification Workflow Guide. Tag the image to match the corresponding RHOSO 18 base image. For example, when the base image is version 18.0.0, the Partner’s image is also tagged as version 18.0.0. You can also use the above example procedure with the other neutron services. Ensure that you use the appropriate RHOSO openstack-neutron base image in place of the openstack-neutron-server base image.
Certify and publish the container image: For information on how to certify the container image, see Red Hat Enterprise Linux Software Certification Policy Guide and Red Hat Software Certification Workflow Guide. You can publish container images in the Red Hat Ecosystem Catalog.

3.2.2. Maintain partner container images and image tags
Copy link

When a Partner certifies their networking solution that includes a container image, then the Partner is responsible for rebuilding that image every time the underlying Red Hat OpenStack Services on OpenShift (RHOSO) container image changes. The Partner must rebuild the container image:

With every RHOSO maintenance release.
When RHOSO container images are updated to address a CVE.

For example, if a Partner certified their solution against RHOSO 18.0.1, the Partner must add two tags to the container image:

18.0.1 to indicate the specific release.
18.0 to indicate this is the latest version associated with RHOSO 18.

When RHOSO 18.0.2 releases, the Partner must rebuild their image and update the images and tags:

The tag for the new image is 18.0.2.
The older 18.0.1 image must remain in the Red Hat Ecosystem Catalog. Partners must not remove old images.
Remove the 18.0 tag from the older 18.0.1 image, and add it to the new 18.0.2 image.

3.2.3. Deploy partner container images
Copy link

With Red Hat OpenStack Services on OpenShift (RHOSO), you can use the OpenStackVersion custom resource definition (CRD) to override the container image for any service. In the following example, the CRD configures a custom image for the neutron-server to use the container image of a Partner named "PartnerX".

apiVersion: core.openstack.org/v1beta1
kind: OpenStackVersion
metadata:
  name: openstack
spec:
  customContainerImages:
    neutronAPIImage: registry.connect.redhat.com/partnerX/openstack-neutron-server-partnerX-plugin:18.0.1

apiVersion: core.openstack.org/v1beta1
kind: OpenStackVersion
metadata:
  name: openstack
spec:
  customContainerImages:
    neutronAPIImage: registry.connect.redhat.com/partnerX/openstack-neutron-server-partnerX-plugin:18.0.1

Copy to Clipboard

Toggle word wrap

3.3. Set custom configuration for the networking driver
Copy link

You can use the OpenStackControlPlane custom resource definition (CRD) extraMounts feature to provide files to the openstack-neutron networking service. One example is if a Partner’s openstack-neutron driver requires an additional configuration file containing authentication credentials to enable access to the Partner’s back-end networking devices. You can store the contents of the file in a Kubernetes secret, which you can create from a YAML file:

apiVersion: v1
kind: Secret
metadata:
  name: cinder-volume-example-config 
type: Opaque
stringData:
  partner_config.ini: | 
	  example_credentials=example

apiVersion: v1
kind: Secret
metadata:
  name: cinder-volume-example-config


type: Opaque
stringData:
  partner_config.ini: |


	  example_credentials=example

Copy to Clipboard

Toggle word wrap

1: The secret name is arbitrary, but this example includes the networking service and the Partner’s name.
2: The name of the file required by the example networking driver is partner_config.ini.
3: Example ini file data.

The following example shows an extraMounts entry in the neutron section of the OpenStackControlPlane CR to mount the config.ini into the neutron-server pod.

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  neutron:
    template:
      databaseAccount: neutron
      databaseInstance: openstack
      memcachedInstance: memcached
      networkAttachments:
    	 - internalapi
      passwordSelectors:
        service: NeutronPassword
      rabbitMqClusterName: rabbitmq
      replicas: 1
      secret: osp-secret
      serviceUser: neutron
      ml2MechanismDrivers:
        - partner-mech-driver		
      customServiceConfig: |		
        [example]
          foo=bar
      extraMounts: 							
      - extraVol:
        - mounts:
          - name: partner-config
            mountPath: /etc/neutron/neutron.conf.d/partner_config.ini 
            subPath: partner_config.ini  
            readOnly: true
          volumes:
          - name: partner-config
            secret:
              secretName: neutron-server-partnerX-config

apiVersion: core.openstack.org/v1beta1
kind: OpenStackControlPlane
metadata:
  name: openstack
spec:
  neutron:
    template:
      databaseAccount: neutron
      databaseInstance: openstack
      memcachedInstance: memcached
      networkAttachments:
    	 - internalapi
      passwordSelectors:
        service: NeutronPassword
      rabbitMqClusterName: rabbitmq
      replicas: 1
      secret: osp-secret
      serviceUser: neutron
      ml2MechanismDrivers:
        - partner-mech-driver


      customServiceConfig: |


        [example]
          foo=bar
      extraMounts:


      - extraVol:
        - mounts:
          - name: partner-config
            mountPath: /etc/neutron/neutron.conf.d/partner_config.ini


            subPath: partner_config.ini


            readOnly: true
          volumes:
          - name: partner-config
            secret:
              secretName: neutron-server-partnerX-config

Copy to Clipboard

Toggle word wrap

1: In a deployment where the Partner’s networking driver integrates with the ML2 networking by using a custom mechanism driver, you can use this section to configure additional mechanism drivers.
2: Use this section to set the neutron-server configuration of the Partner driver. You can use this section to provide custom configuration in the CR. You should use secrets to provide information such as credentials. Note that secrets are stored unencrypted by default in the Kubernetes API server. For more information about Kubernetes secrets, see kubernetes documentation.
3: Use this section to set the extraMounts configuration for the neutron section of the OpenStackControlPlane.
4: Use this section to set the mount point where the partner_config.ini file appears in the neutron-server pod.
5: Use this section to set the subPath to specify the partner_config.ini filename. This is necessary to mount a single file in the /etc/neutron/neutron.conf.d directory.
6: The secretName value matches the name of the secret that you created previously.

3.4. Deploy the networking driver agent on the EDPM nodes
Copy link

If your networking solution requires a specific agent running on the External DataPlane Nodes (EDPM), you can deploy on such nodes by using a custom OpenStackDataPlaneService custom resource (CR) and adding the agent to the OpenStackDataPlaneNodeSet CR. If your networking solution requires a specific agent running on the Red Hat OpenShift Container Platform (RHOCP) nodes with the neutron-server, you can add a custom Kubernetes operator by using operator-sdk. Ensure that you provide specific custom resource definitions (CRDs) that are not integrated with the Red Hat OpenStack Services on OpenShift (RHOSO) openstack-operator for the new operator.

3.4.1. Building partner ansible-runner image
Copy link

You can build a Partner ansible-runner image so that you can streamline Ansible tasks that are required to install and configure the Networking agents.

Procedure

Create a Containerfile for generating the container image. The following example shows a sample Containerfile or Dockerfile for generating a ansibleee-runner container image that includes additional roles and playbooks that are required by a Partner’s OpenStackDataPlaneService.
```
FROM quay.io/openstack-k8s-operators/openstack-ansibleee-runner:latest
COPY neutron_agent_partner_role /usr/share/ansible/roles/neutron_agent_partner_role 
COPY playbooks/neutron_agent_partner.yaml /usr/share/ansible/collections/ansible_collections/osp/edpm/playbooks/		  
```
```
FROM quay.io/openstack-k8s-operators/openstack-ansibleee-runner:latest
COPY neutron_agent_partner_role /usr/share/ansible/roles/neutron_agent_partner_role 
```
1
```
COPY playbooks/neutron_agent_partner.yaml /usr/share/ansible/collections/ansible_collections/osp/edpm/playbooks/		  
```
2
Copy to Clipboard Toggle word wrap
1
Add Partner’s role to the container image.
2
Add the playbook to run the Partner’s role to the container image. This step is optional. You can pass playbook content to the service directly in the OpenStackDataPlaneService file. For more information see, Customizing the data plane in Customizing the Red Hat OpenStack Services on OpenShift deployment.
Build, tag, and upload the container image. You can use the podman build or buildah build commands to build the container image. For more information on how to choose a registry and provide an access token to the registry for the certification, see the Red Hat Software Certification Workflow Guide.
Tag the image to match the corresponding RHOSO 18 base image. For example, when the base image is version 18.0, the Partner’s image is also tagged as version 18.0.
Certify and publish the container image: For information on how to certify the container image, see Red Hat Enterprise Linux Software Certification Policy Guide and Red Hat Software Certification Workflow Guide. You can publish container images in the Red Hat Ecosystem Catalog.

3.4.2. Deploy the partner solution on the EDPM nodes
Copy link

The following example shows a custom service definition (CRD) that you might use to deploy the Partner solution:

apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneService
metadata:
  name: neutron-custom-partner-service						
spec:
  label: dataplane-deployment-neutron-custom-partner-service
  playbook: osp.edpm.neutron_agent_partner  					
  openStackAnsibleEERunnerImage: openstack-ansibleee-partnerX-runner:latest

apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneService
metadata:
  name: neutron-custom-partner-service


spec:
  label: dataplane-deployment-neutron-custom-partner-service
  playbook: osp.edpm.neutron_agent_partner


  openStackAnsibleEERunnerImage: openstack-ansibleee-partnerX-runner:latest

Copy to Clipboard

Toggle word wrap

1: The name of the custom service, that is used in the OpenStackDataPlaneNodeSet CR to add the service to the service list.
2: The playbook that runs as part of the custom service deployment. It must be available in the custom ansibleee image.
3: The custom container image, that the ansible-runner execution environment uses to execute Ansible.

For more information about how to define a custom service, see Customizing the data plane in Customizing the Red Hat OpenStack Services on OpenShift deployment.

The following example shows how to enable a custom service in the EDPM NodeSet. To deploy a custom service on the EDPM nodes, you must include it in the services list in the OpenStackDataPlaneNodeSet CR:

apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneNodeSet
metadata:
  name: openstack-edpm
spec:
  services:
    - download-cache
    - bootstrap
    - configure-network
    - validate-network
    - install-os
    - configure-os
    - run-os
    - neutron-custom-partner-service							
    - libvirt
    - nova
  nodes:
    edpm-compute:
      ansible:
        ansibleHost: 172.20.12.67
        ansibleSSHPrivateKeySecret: dataplane-ansible-ssh-private-key-secret
        ansibleUser: cloud-admin
        ansibleVars:
          ansible_ssh_transfer_method: scp
          ctlplane_ip: 172.20.12.67
          external_ip: 172.20.12.76
          fqdn_internalapi: edpm-compute-1.example.com
          internalapi_ip: 172.17.0.101
          storage_ip: 172.18.0.101
          tenant_ip: 172.10.0.101
      hostName: edpm-compute-0
      networkConfig: {}
      nova:
        cellName: cell1
        deploy: true
        novaInstance: nova

apiVersion: dataplane.openstack.org/v1beta1
kind: OpenStackDataPlaneNodeSet
metadata:
  name: openstack-edpm
spec:
  services:
    - download-cache
    - bootstrap
    - configure-network
    - validate-network
    - install-os
    - configure-os
    - run-os
    - neutron-custom-partner-service


    - libvirt
    - nova
  nodes:
    edpm-compute:
      ansible:
        ansibleHost: 172.20.12.67
        ansibleSSHPrivateKeySecret: dataplane-ansible-ssh-private-key-secret
        ansibleUser: cloud-admin
        ansibleVars:
          ansible_ssh_transfer_method: scp
          ctlplane_ip: 172.20.12.67
          external_ip: 172.20.12.76
          fqdn_internalapi: edpm-compute-1.example.com
          internalapi_ip: 172.17.0.101
          storage_ip: 172.18.0.101
          tenant_ip: 172.10.0.101
      hostName: edpm-compute-0
      networkConfig: {}
      nova:
        cellName: cell1
        deploy: true
        novaInstance: nova

Copy to Clipboard

Toggle word wrap

1: The name of the service matches the service created previously. Add the service name in the order of execution relative to the other services. This example shows deploys the neutron-custom-partner-service after run-os and before the libvirt service. This order is important for dependencies because services are executed simply in the order from the list.

Legal Notice
Copy link

The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Integrating partner content

Integrating and certifying third-party software and hardware for Red Hat OpenStack Services on OpenShift

OpenStack Documentation Team

Providing feedback on Red Hat documentation
Copy link

Chapter 1. Integrating and certifying with RHOSO
Copy link

1.1. General Certification Prerequisites
Copy link

Chapter 2. integrating RHOSO storage services
Copy link

2.1. Configuring the storage driver
Copy link

2.2. Adding software dependencies for the storage driver
Copy link

2.2.1. Building partner container images
Copy link

2.2.2. Maintaining partner container images and image tags
Copy link

2.2.3. Deploying partner container images
Copy link

2.3. Accessing extra files for the storage driver
Copy link

Chapter 3. Integrating RHOSO networking services
Copy link

3.1. Configure the networking driver
Copy link

3.2. Prepare neutron-api component with the new networking driver
Copy link

3.2.1. Building partner container images for networking services
Copy link

3.2.2. Maintain partner container images and image tags
Copy link

3.2.3. Deploy partner container images
Copy link

3.3. Set custom configuration for the networking driver
Copy link

3.4. Deploy the networking driver agent on the EDPM nodes
Copy link

3.4.1. Building partner ansible-runner image
Copy link

3.4.2. Deploy the partner solution on the EDPM nodes
Copy link

Legal Notice
Copy link

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Integrating partner content

Integrating and certifying third-party software and hardware for Red Hat OpenStack Services on OpenShift

OpenStack Documentation Team

Providing feedback on Red Hat documentationCopy linkLink copied to clipboard!

Chapter 1. Integrating and certifying with RHOSOCopy linkLink copied to clipboard!

1.1. General Certification PrerequisitesCopy linkLink copied to clipboard!

Chapter 2. integrating RHOSO storage servicesCopy linkLink copied to clipboard!

2.1. Configuring the storage driverCopy linkLink copied to clipboard!

2.2. Adding software dependencies for the storage driverCopy linkLink copied to clipboard!

2.2.1. Building partner container imagesCopy linkLink copied to clipboard!

2.2.2. Maintaining partner container images and image tagsCopy linkLink copied to clipboard!

2.2.3. Deploying partner container imagesCopy linkLink copied to clipboard!

2.3. Accessing extra files for the storage driverCopy linkLink copied to clipboard!

Chapter 3. Integrating RHOSO networking servicesCopy linkLink copied to clipboard!

3.1. Configure the networking driverCopy linkLink copied to clipboard!

3.2. Prepare neutron-api component with the new networking driverCopy linkLink copied to clipboard!

3.2.1. Building partner container images for networking servicesCopy linkLink copied to clipboard!

3.2.2. Maintain partner container images and image tagsCopy linkLink copied to clipboard!

3.2.3. Deploy partner container imagesCopy linkLink copied to clipboard!

3.3. Set custom configuration for the networking driverCopy linkLink copied to clipboard!

3.4. Deploy the networking driver agent on the EDPM nodesCopy linkLink copied to clipboard!

3.4.1. Building partner ansible-runner imageCopy linkLink copied to clipboard!

3.4.2. Deploy the partner solution on the EDPM nodesCopy linkLink copied to clipboard!

Legal NoticeCopy linkLink copied to clipboard!

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Providing feedback on Red Hat documentation
Copy link

Chapter 1. Integrating and certifying with RHOSO
Copy link

1.1. General Certification Prerequisites
Copy link

Chapter 2. integrating RHOSO storage services
Copy link

2.1. Configuring the storage driver
Copy link

2.2. Adding software dependencies for the storage driver
Copy link

2.2.1. Building partner container images
Copy link

2.2.2. Maintaining partner container images and image tags
Copy link

2.2.3. Deploying partner container images
Copy link

2.3. Accessing extra files for the storage driver
Copy link

Chapter 3. Integrating RHOSO networking services
Copy link

3.1. Configure the networking driver
Copy link

3.2. Prepare neutron-api component with the new networking driver
Copy link

3.2.1. Building partner container images for networking services
Copy link

3.2.2. Maintain partner container images and image tags
Copy link

3.2.3. Deploy partner container images
Copy link

3.3. Set custom configuration for the networking driver
Copy link

3.4. Deploy the networking driver agent on the EDPM nodes
Copy link

3.4.1. Building partner ansible-runner image
Copy link

3.4.2. Deploy the partner solution on the EDPM nodes
Copy link

Legal Notice
Copy link