Chapter 1. Introduction
The Red Hat OpenStack Certification Policy guide delineate policy overview to certify third-party vendor solutions with Red Hat OpenStack Platform. Red Hat encourages Partners to test their plugins with pre-releases of both Red Hat builds and pre-releases of their own solutions.
This guide describes the technical certification requirements as implemented for software certification Partners who want to offer their own applications, management applications or plugin/driver software for use with RHOSP in a jointly supported customer environment.
1.2. Creating Value for Our Joint Customers
The certification process includes a series of tests that provides Red Hat Customers with the assurance that a certified solution meets all the requirements of an enterprise cloud. The certification process is jointly supported by Red Hat and Partner’s organization.
The Red Hat OpenStack Certification Workflow Guide includes multiple tests, each with a series of subtests and checks, which are explained in this guide. All tests are not required for each certification.
Logs from a single run with all of the mandatory tests and the test suite self-check test (rhcert/selfcheck) must be submitted to Red Hat for new certifications and for recertifications. For more information on running the tests, see Red Hat OpenStack Certification Workflow Guide.
The certification tooling and workflow documented in the article will be supported for a period of 90 days to support certifications which are underway.
Red Hat encourages Partners to install and use the latest version of the certification tooling and workflow for the certification process. A 90 day grace period is provided for the previous version of the tooling and workflow upon a new release of the certification tooling. This allows already in progress certifications to be completed without disruption. At the end of the grace period, test results generated using earlier versions of tooling will no longer be accepted.
The latest version of the certification tooling and workflow is available via Red Hat Subscription Management and documented in the Red Hat OpenStack Certification WorkFlow Guide.
Most of the certification subtests provide an immediate return status (Pass/Fail), however, some subtests may require detailed review by Red Hat to confirm success. Such tests are marked with Review status in Red Hat Certification application.
Some tests may also identify a potential issue and return a Warn status. This status indicates that best practices have not been followed. Tests marked with the Warn status warrant attention or action(s) but do not prevent a certification from succeeding. Partners are recommended to review the output of such tests and perform appropriate action(s) based on the information contained within the warnings.
1.3. RHOSP Certification Prequisites
The following certification eligibility summarizes the prerequisites that Partners need in order to meet the OpenStack Certification requirements:
- Companies must be Partners in Red Hat Connect for Technology Partners. This program enables an ecosystem for commercial OpenStack deployments and includes numerous technology companies
Partners must have a support relationship with Red Hat. This can be fulfilled through:
- custom support agreement, or
- TSANet. See the TSANet web page for more information
- Partners must have a good working knowledge of RHOSP including installation and configuration of the product
- Partners must provide a link to an installation guide for the OpenStack plugin being certified. This installation guide must indicate the usage of Red Hat Director for the OpenStack deployment.
1.4. RHOSP Component Distribution
As part of RHOSP, Red Hat distributes components that are committed in a release of the upstream OpenStack project such as Kilo, Liberty, and so on. These components are called In tree components. Partners are still responsible for certification and for distribution of all their dependencies that are not part of the upstream OpenStack project.
Distribution of products or components that are not committed in the upstream OpenStack project is the responsibility of the Partner. These components are also referred to as Out of tree components.