Red Hat OpenStack Certification
Last updated
Last updated
Red Hat OpenStack Certification is offered to partners who want to offer their own applications, management applications or plug-in/driver software for use with Red Hat OpenStack Platform in a jointly supported customer environment. The diagram below shows the various certifications at play when they come to Red Hat OpenStack Platform.
To learn more about Red Hat OpenStack Certification benefits please visit the following page: https://connect.redhat.com/en/partner-with-us/red-hat-openstack-certification
If this is your first time to certify with Red Hat OpenStack Platform or you need a refresh on the actual process, please request an orientation session via our Red Hat Technology Partner Success Desk TPSD with the Ecosystem Partner Management (EPM) Team. Please select the "Certification" category and Red Hat OpenStack Platform for the product. The intent of this session is to review the overall certification process and answer any questions you may have.
The prerequisites for any OpenStack driver or service need to be understood prior to getting started on your certification journey. Below are the driver certification prerequisites for Neutron, Cinder and Manila. Please request information on the requirements for any other service or driver not found here.
As of Red Hat OpenStack Platform release 13, all OpenStack Services are containerized.
Partner Cinder driver must be present in OpenStack Cinder Upstream Project as Red Hat does not ship any Cinder driver that is not present in Cinder Upstream Project. For help on contributing Upstream to OpenStack please consult the Openstack Contributor Guide available at: https://docs.openstack.org/contributors/ and more specifically to contribute to Upstream Cinder Project, please consult the following site: https://docs.openstack.org/cinder/latest/contributor/index.html
Partner Cinder driver must be available in the OpenStack Cinder Upstream branch associated with the Red Hat OpenStack Platform release you intend to certify against. For example:
Red Hat OpenStack Platform 13 is based on OpenStack Upstream Queens.
Red Hat OpenStack Platform 16 is based on OpenStack Upstream Train. This includes Red hat OpenStack 16.1, 16.2.
Cinder driver must pass 3rd party CI. Each supported storage protocol for the vendor driver is not required to have a 3rd party Upstream CI, but each protocol will have to pass Red Hat OpenStack certification. For details please visit Cinder/tested-3rdParty-drivers - OpenStack.
Partner Cinder driver should be deployed and configured using Red Hat OpenStack Platform director. Director deploys all services as containers, the driver must therefore support running inside a cinder volume container. Partners are expected to provide a deployment guide that is suitable for customers to deploy the partner's driver.
A good understanding of Red Hat OpenStack Platform director is mandatory. Red Hat Training as well as documentation are available to gain expertise.
A Custom Block Storage Back End Deployment Guide is available here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/custom_block_storage_back_end_deployment_guide/
Please note that the use of an OpenStack Standalone "all in one" deployment can be leveraged to get familiar with director and do early development and integration of your driver. A standard deployment will still be required during the certification phase.
Please refer to our Quick Start Guide for Red Hat OpenStack Platform 16.1 available here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/quick_start_guide/.
If the partner Cinder driver requires additional software to be deployed, for example: partner-specific python modules, partner-specific application codes along with the Cinder driver, then the partner is required to build a customised version of the Red Hat provided cinder-container image. That customised cinder-volume container image will be based on the standard Red Hat Cinder volume image and include all the external dependencies required by the driver
The customised cinder-volume container image will have to go through the container image certification prior to being able to run the Red Hat OpenStack Cinder certification.
A separate customised cinder-volume container image will have to be built and maintained for each Major.Minor release of Red Hat OpenStack Platform starting with RHOSP 16.0. Every time a Red Hat OpenStack Platform z-stream is released for a given Major.Minor release, partners are expected to rebuild their customised cinder-volume container image.
The steps required to build and certify your customised cinder-volume container image are described here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/partner_integration/building-certified-container-images
We take that opportunity to encourage our partners to Upstream those external dependencies and integrate those via RDO and into Red Hat OpenStack Platform as an alternative to have to maintain a separate customised cinder-volume container image. To learn more about RDO, please consult the following site: https://www.rdoproject.org/documentation/rdo-packaging
Please note that this container image certification is not the same as the Red Hat OpenStack certification. The certified customised container image is used to deploy your vendor-specific dependency, which is then used as part of the Red Hat OpenStack deployment that includes the Cinder vendor driver to be certified as a complete Red Hat OpenStack solution.
To complete the Red Hat OpenStack Cinder Certification, the cinder driver will have to pass a set of mandatory feature tests per supported protocol that are defined here: https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/7.24/html/red_hat_openstack_certification_policy_guide/openstack-cinder-overview . Any additional optional features provided by your cinder driver will be required to pass a corresponding feature test per supported protocol as well.
Partner Manila driver must be present in OpenStack Manila Upstream Project as Red Hat does not ship any Manila driver that is not present in Manila Upstream Project. For help on contributing Upstream to OpenStack please consult the Openstack Contributor Guide available at: https://docs.openstack.org/contributors/ and more specifically to contribute to Upstream Manila Project, please consult the following site: https://docs.openstack.org/manila/latest/contributor/index.html
Partner Manila driver must be available in the OpenStack Manila Upstream branch associated with the Red Hat OpenStack Platform release you intend to certify against. For example:
Red Hat OpenStack Platform 13 is based on OpenStack Upstream Queens.
Red Hat OpenStack Platform 16 is based on OpenStack Upstream Train. This includes Red Hat OpenStack 16.1, 16.2.
Manila driver must pass 3rd party CI for the current development branch. We recommend testing against the stable branch associated with the Red Hat OpenStack Platform release you intend to certify against. For details please visit Manila driver maintenance requirements.
Partner Manila driver should be deployed and configured using Red Hat OpenStack Platform director. Director deploys all services as containers, the driver must therefore support running inside a manila share container. Partners are expected to provide a deployment guide that is suitable for customers to deploy the partner's driver.
A good understanding of Red Hat OpenStack Platform director is mandatory. Red Hat Training as well as documentation are available to gain expertise.
Backend configuration management is expected to be integrated into Director. This is done via the upstream tripleo-heat-templates, puppet-tripleo and puppet-manila projects. If the backend driver that’s being certified does not have such integration, an approach similar to a custom cinder backend can be used. Please see the Custom Block Storage Back End Deployment Guide here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/custom_block_storage_back_end_deployment_guide/index
Please note that the use of an OpenStack Standalone "all in one" deployment can be leveraged to get familiar with director and do early development and integration of your driver. A standard deployment will still be required during the certification phase.
Please refer to our Quick Start Guide for Red Hat OpenStack Platform 16.1 available here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/quick_start_guide/.
If the partner Manila driver requires additional software to be deployed, for example: partner-specific python modules, partner-specific application codes along with the Manila driver, then the partner is required to build a customised version of the Red Hat provided manila-container image. That customised manila-container image will be based on the standard Red Hat Manila image and include all the external dependencies required by the driver.
We take that opportunity to encourage our partners to Upstream those external dependencies and integrate those via RDO and into Red Hat OpenStack Platform as an alternative to have to maintain a separate customised manila container image. To learn more about RDO, please consult the following site: https://www.rdoproject.org/documentation/rdo-packaging
The customised manila container image will have to go through the container image certification prior to being able to run the Red Hat OpenStack Manila certification.
A separate customised manila container image will have to be built and maintained for each Major.Minor release of Red Hat OpenStack Platform starting with RHOSP 16.0. Every time a Red Hat OpenStack Platform z-stream is released for a given Major.Minor release, partners are expected to rebuild their customised manila container image.
The steps required to build and certify your customised manila container image are described here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/partner_integration/building-certified-container-images
Please note that this container image certification is not the same as the Red Hat OpenStack certification. The certified customised container image is used to deploy your vendor-specific dependency, which is then used as part of the Red Hat OpenStack deployment that includes the Manila vendor driver to be certified as a complete Red Hat OpenStack solution.
To complete the Red Hat OpenStack Manila Certification, the manila driver will have to pass a set of mandatory feature tests per supported protocol that are defined here: https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/7.24/html/red_hat_openstack_certification_policy_guide/openstack-manila-overview
Any additional optional features provided by your manila driver will be required to pass a corresponding feature test per supported protocol as well.
The partner provided Neutron ML2 Plugins and drivers do not not need to be present in the OpenStack Neutron Upstream Project.
The partner provided Neutron ML2 Plugins and drivers should be deployed and configured using Red Hat OpenStack Platform director. Partners are expected to provide a deployment guide that is suitable for customers to deploy the partner's driver.
Partners must have a good understanding of Red Hat OpenStack Platform director. Red Hat Training as well as documentation are available to gain expertise.
Partner is expected to have the following nodes as part of their deployment:
Minimum of 3 controller nodes (Physical or Virtual)
Minimum of 2 networker nodes (Physical or Virtual)
Minimum of 2 computes nodes (Physical or Virtual)
Partner should identify the respective nodes as well.
Please note that the use of an OpenStack Standalone "all in one" deployment can be leveraged to get familiar with director and do early development and integration of your driver. A standard deployment will still be required during the certification phase.
Please refer to our Quick Start Guide for Red Hat OpenStack Platform 16.1 available here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/quick_start_guide/
Because the partner Neutron ML2 Plugins and drivers are not part of the OpenStack Neutron Upstream Project, the partner is always required to build a customised version of the Red Hat provided Neutron server container image. That customised Neutron server container image will include all the external dependencies required by the driver.
The customised Neutron Server container image will have to go through to Container image certification prior to be able to run the Red Hat OpenStack certification.
Any additional container images required beside the Neutron server container image must pass the container image certification
Separate customised Neutron server container image will have to be built and maintained for each Major.Minor release of Red Hat OpenStack Platform starting with RHOSP 16.0. Every time a Red Hat OpenStack Platform z-stream is released for a given Major.Minor release, partners are expected to rebuild their customised Neutron server container image.
The steps required to certify your customised Neutron server container images and any additional container images are described here: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/partner_integration/building-certified-container-images
Please note that this container image certification is not the same as the Red Hat OpenStack certification. The certified customised container image is used to deploy your vendor-specific dependency, which is then used as part of the Red Hat OpenStack deployment that includes the Neutron vendor driver to be certified as a complete Red Hat OpenStack solution.
To complete the Red Hat OpenStack Neutron Certification, the Neutron ML2 Plugin and driver will have to pass a set of mandatory feature tests that are defined here:
https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/7.18/html/red_hat_openstack_certification_policy_guide/openstack-neutron-overview Any additional optional features provided by your neutron driver will be required to pass a corresponding feature test.
