Build certified partner container images

Build a Red Hat certified container image to layer external software dependencies on top of Red Hat’s RHOSO cinder-volume or manila-share container image when your Partner storage driver requires them.

About this task

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.

Procedure

  1. Create a Containerfile for generating the container image:
    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 defines 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.
    • LABEL defines the labels that override the corresponding labels in the base image to uniquely identify the Partner’s image.
    • You can install the software dependencies by enabling a repo to install a package, installing a package over the network, installing a local package, or installing a python package from PyPI.
  2. 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.

  3. 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.

Partner container image maintenance

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.