Å·²©ÌåÓýƽ̨

Introduction 

Å·²©ÌåÓýƽ̨ Red Hat OpenShift software certification program is designed to help service providers and partners ensure that their software products are compatible with the Red Hat platform. It also validates that solutions building on the Red Hat platform are consistent, interoperable, and supported. Å·²©ÌåÓýƽ̨ program includes Red Hat Container, Helm Chart and Operator Certification, as well as Workload Best Practice Certification. For Telco workload, this is called Containerized Network Functions (CNFs) Best Practice Certification (BPC). To achieve workload BPC, workload needs to be Partner Validated on OpenShift Platform first. Various workflows are organized by certification types and tools. For example, the container and operator bundle image certification are managed by the certification tool and Red Hat Connect Portal. Helm chart certification is managed by the tool, Helm Chart hub and Connect Portal. Red Hat workload Partner Validate uses Partner Portal only. Workload Best Practice Certification needs both Partner Portal and tool. Å·²©ÌåÓýƽ̨ detailed guidance for each certification is described in the official guide . 

Developed with Ansible, one-shot certification automation to provide automated processes for all aforementioned certifications and seamlessly publish to Red Hat’s ecosystem catalog. This article describes the workflow for one-shot automation covering Red Hat Container, Helm Chart and Operator Certification as well as workload Partner Validate and Best Practice Certification.

One-shot workload certification workflow 

Å·²©ÌåÓýƽ̨ sequence diagrams below illustrate the end-to-end automation workflow of the one-shot certification automation using Red Hat’s Distributed CI (DCI) pipeline. Each sub-diagram represents a specific workload certification â€� container, Helm chart, and operator - illustrating how the pipeline triggers certification tasks, runs valid workload certification processes using certification test tools like Preflight and Chart Verifier, and submits results to Red Hat’s Partner Portal or GitHub repositories. Å·²©ÌåÓýƽ̨ workload best practice certification is the most comprehensive, requiring certification of container images, Helm chart or operator, as well as the workload best practice certification for K8s testing. Through the one-shot automation process, this is achieved by integrating multiple certification pipelines and executed sequentially. Å·²©ÌåÓýƽ̨ workload certification diagram illustrates the workload best practice tests for K8s and outlines conditional paths for handling pass, fail, and exception outcomes. Å·²©ÌåÓýƽ̨se diagrams serve as visual guides to help users understand how certification tasks are executed, monitored automatically, and how the product as a whole is published to catalog in a streamlined, repeatable manner. 
 

Container certification

Image

Step 1. User starts the automation process by working with DCI-Pipeline config. User prepares a DCI pipeline YAML configuration file (). This config defines the parameters for certifying the container image â€� including container name, registry path, credentials, product listing ID etc. Note: Å·²©ÌåÓýƽ̨ DCI-pipeline schedule command will use this config to automate the process. 

Step 2-3. Create Container Certification Project via Partner Portal API. Using DCI automation, a new Container Certification project is created on the Red Hat Partner Connect Portal automatically. Every container to be certified needs a dedicated project space in the Partner Portal. DCI agent communicates with Red Hat’s Pyxis API to create the project, update all the mandatory parameters and then attach Product-listing to Certification Project based on the product ID in the YAML file. Product-listing ensures that the certified container can be published and visible to customers. 

Step 4-5. Run Preflight Certification tests and submit test results automatically (Å·²©ÌåÓýƽ̨ container image for certification is pre-pushed to a publicly accessible container registry e.g., Quay.io, DockerHub etc). Test results, including logs and artifacts and container repository info, are collected and automatically uploaded back to the Red Hat Partner Portal via API. DCI triggers the Preflight tool to run full certification tests either using sequential or parallel mode. 

Step 6. Red Hat Partner Portal will trigger container vulnerability scans and provide a health index grade. 

Step 7. Container is validated and Red Hat partner portal requests to publish to the Red Hat Ecosystem Catalog. 

Step 8. Å·²©ÌåÓýƽ̨ Hooks were used to wait until the container images were published to the catalog. 

Step 9-10. Å·²©ÌåÓýƽ̨ validated container image is published under the associated Product-listing automatically, and is managed by the catalog update process. DCI will check status and log it.

Helm chart certification

Image

Step 1. User starts the automation process by working with DCI pipeline config. Set up () by defining necessary parameters such as chart tarball location, GitHub repo, Pyxis credentials, Product-Listing ID, etc. This config will drive the certification steps automatically. 

Step 2-4. Create Helm Chart Certification Project. DCI creates a new Helm Chart Certification project in the Red Hat Partner Connect Portal via Pyxis API, attached to Product-listing to Certification Project Partner Portal will trigger a new helm chart owner file and pull request to Red Hat’s chart hub. 

Step 5-6. Run Chart Verifier tests procedure. DCI will invoke the Chart Verifier tool automatically to validate the candidate helm chart. Chart Verifier will then deploy the workload onto the user’s OpenShift cluster and perform the chart tests. 

Step 7-8. Submit test results and artifact. Submit the Chart Verifier report and Helm chart artifact by creating a GitHub Pull Request to Red Hat’s OpenShift Helm Chart Hub. 

Step 9-10. Red Hat review and merge chart. Red Hat Helm Chart Hub will review the PR, if all tests pass, it merges the chart into the hub. 

Step 11. Publish Certified Helm Chart. Helm Chart project status in Red Hat’s partner portal will be updated and the certified helm chart becomes publicly available in OpenShift’s Helm Chart Hub.

Operator certification

Image

Step 1. User prepares a DCI operator pipeline YAML configuration file. () This includes parameters for certifying both the operator bundle and its container image â€� including bundle image path, container registry, GitHub credentials, Product-listing ID etc. 

Step 2-3. Create Operator Certification Projects via Partner Portal API. DCI automation creates two related projects on Red Hat Partner Portal: 

• One for Operator Certification (for the operator bundle itself)
• One for Container Certification (for operator relatedImages e.g. CSV containers )  

Note: Red Hat tracks operator certification separately from the container image. 

Step 4-6. Run Preflight tests automatically on container and operator. DCI triggers Preflight tests on both: 

• Å·²©ÌåÓýƽ̨ operator bundle image (validating operator metadata, manifests, OLM, scorecard tests)
• Å·²©ÌåÓýƽ̨ container images (scanning CVEs, labels etc)
• Submit Preflight test results from container and operator Preflight runs are collected and submitted back to Red Hat Partner Portal automatically. 

Step 7-8. Submit operator bundle to Red Hat Operator Hub GitHub Repository Automation creates a Pull Request (PR) into Red Hat’s Certified Operators GitHub repo (community-operators-prod). PR includes the operator bundle metadata. Note: Red Hat certifies operators through GitHub PR submission rather than only Portal upload. 

Step 9. Publish Certified Operator in OperatorHub. After a successful PR merge, the operator appears in Red Hat’s Certified OperatorHub. Outcome: Customers can deploy the operator via OpenShift OperatorHub marked as “Certified.�

Workload partner validate, workload best practice certification

Image

Step 1. User prepares a DCI pipeline YAML configuration file. (). This pipeline defines the tasks required for a candidate workload to go through workload project creation and execute Red Hat best practice certification for Kubernetes CertSuite tool for workload best practice certification). For workload best practice certification, the one-shot automation integrates this pipeline with additional certification pipelines, such as container, Helm chart, or operator certification. 

Step 2. DCI pipeline creates a new workload certification project in the Partner Portal using the Red Hat Pyxis API. This project will serve for workload partner validation, workload best practices certification. 

Step 3. Red Hat Partner portal will also trigger a Cert-Ops case for tracking the progress of workload corresponding certification. For workload partner validation, once the partner completes all mandatory pre-check tasks defined in the workload project, the Red Hat case owner will mark the workload as partner-validated and publish it to the Red Hat Ecosystem Catalog. 

Step 4. DCI pipeline invokes the Red Hat Best Practices Certification for K8s Certsuite to run best practice test cases against the workload. Note, workload must be fully deployed, and operational on the OpenShift platform before performing best practices testing. 

Step 5-6. CertSuite generates test results in a tarball file and upload this result to:

• DCI Control Server (internal record)
• Red Hat Cert-ops (certification case management) 

Step 7-9. Red Hat Certification case review and publication. Å·²©ÌåÓýƽ̨ submitted CertSuite test results will be parsed in the Cert-ops backend automatically. Conditional paths: 

• All test cases passed, Cert-ops will certify workload automatically and the product will be published to catalog as Red Hat certified.
• If some test cases fail, the partner will go into a manual process for clarification, fixes, or exception requests for failed cases. Once all failure cases have been handled, workload will be certified and published to catalog by Red Hat case owner. 

One-shot automation setup 

• Openshift Cluster & Access:
  • Functional OCP cluster.
  • Accessible kubeconfig to test Cluster (e.g., 
    /var/lib/dci-openshift-app-agent/my-kubeconfig/).
• Red Hat Account:
  • Portal account.
  • Partner Portal credentials: Pyxis API key (Create Pyxis API Key).
  • will be used as parameter in one-shot workload CertSuite to upload results.tar to CertOps.
  • Organization ID (Company ID) for certification projects (company profile).
• DCI Tooling:
  • DCI (Red Hat Distributed CI) for one-shot automation ().
  • Install dci-openshift-app-agent (): 
    sudo dnf upgrade --nobest --refresh --repo dci,epel -y
  • Install dci-pipeline () and clone oneshot-certification-pipeline-template()
  • Create DCI Control Server access credentials ().
• GitHub Token:
  • GitHub token for Helm chart/operator artifacts; save to /opt/cache/dcicertbot-token.txt ().
• Red Hat Product Listing:
  • Create a Product Listing in the Red Hat Partner Portal ()

Execute one-shot automation process to certify a workload and publish to Red Hat’s catalog

After all settings of each component certification have been properly configured, one can run all certification pipeline tasks defined in yml files using dci-pipeline-schedule command line on execute. 

• Option 1. Workload best practice certification using Helm Chart as deployment 

$ export KUBECONFIG=~/my-kubeconfig/kubeconfig 
$ oc project oneshot 
# option1, workload with helm chat as deployment 
$ KUBECONFIG=$KUBECONFIG dci-pipeline-schedule oneshot-container 
oneshot-helmchart oneshot-cnf-certsuite 

• Option 2. Workload best practice certification with operator as deployment 

$ export KUBECONFIG=~/my-kubeconfig/kubeconfig 
# option2, workload with operator as deployment 
$ KUBECONFIG=$KUBECONFIG dci-pipeline-schedule oneshot-container oneshot-operator oneshot-cnf-certsuite 

Other certification scenarios: 

• Container certification only 
  Using pipeline config yaml:

$ export KUBECONFIG=~/my-kubeconfig/kubeconfig 
# container certiification only 
$ KUBECONFIG=$KUBECONFIG dci-pipeline-schedule container-certification 

• Container recertification only 
  Using pipeline config yaml:

 $ export KUBECONFIG=~/my-kubeconfig/kubeconfig 
# container recertiification 
$ KUBECONFIG=$KUBECONFIG dci-pipeline-schedule container-recertification 

• Workload Partner Validate only 
  Using pipeline config yaml:

$ export KUBECONFIG=~/my-kubeconfig/kubeconfig 
# workload partner validate 
$ KUBECONFIG=$KUBECONFIG dci-pipeline-schedule create-openshift-cnf 

• Workload best practice test only 
  Using pipeline config yaml:  

$ export KUBECONFIG=~/my-kubeconfig/kubeconfig 
# workload partner validate 
$ KUBECONFIG=$KUBECONFIG dci-pipeline-schedule cnf-bestpractice-helmchart-kbpc 

Helm Chart’s artifact and certification report can be found in Github
Pull request Merge status can be found in the Merged . 

Partner Product and its components publication on Red Hat’s Catalog. 

Conclusion 

Å·²©ÌåÓýƽ̨ one-shot automation approach simplifies and speeds up the workload certification process by combining all required procedures into a single or multiple pipelines. By using Red Hat’s Distributed CI and certification tools like Preflight, Chart Verifier, and CertSuite, partners can run validations, submit results, and manage their certified product more efficiently. This setup not only saves time but also reduces the chances of manual errors and helps ensure consistency across different certification stages. With everything handled in one workflow, partners can focus on their workloads while meeting certification requirements more easily and reliably. 

Appendix 

A full user guide of use this one-shot process for workload certification including preliminary check process, can be found