A developer sitting in a swivel with a laptop on her lap. Floating in the background are clouds, servers, and applications

Training

Certification with DCI on OpenShift Partner Labs

August 8, 2024
5 minute read
Related products: Red Hat OpenShift

Certification with DCI on OpenShift Partner Labs 

Learn how your team can automate the certification process by running all required certifications—preflight for containers, preflight for operators, chart verifier for Helm charts, and Red Hat Best Practices Test Suite for Kubernetes certification— in one batch using DCI (Distributed CI) pipelines running on OpenShift Partner Labs in ROSA. 

Managing certification with DCI

What is Distributed CI

DCI (Distributed CI) is a CI (Continuous Integration) tool written in Ansible that provides teams the advantage of scheduling the deployment of OCP clusters with multiple installers, automate the deployment of your plugins and workloads, and execute various tests seamlessly.

Design overview of DCI on OpenShift Partner Labs

DCI app-agent is tailored for deployment on a jumpbox — a Red Hat Enterprise Linux (RHEL) machine with an NFR subscription and access to the OCP cluster via kubeconfig. The user operating DCI should possess local sudo permissions and administrative privileges within the cluster.

OpenShift Partner Labs (OPL) is a service we provide to partners by request from Red Hat sponsors. This offering includes ROSA (OCP on AWS). Using a ROSA cluster via OPL, the ROSA CLI is recommended for managing clusters since there isn't a dedicated jumpbox created by default. 

To satisfy the jumpbox requirement while using one of our ROSA clusters, you can set up a local RHEL8 Vagrant VM on your laptop with an NFR subscription. This is an effective jumpbox solution and can serve as a central hub for managing DCI workflows and integrating with ROSA clusters via locally-copied kubeconfig. Additionally, we configure DCI-queue to streamline certification jobs efficiently.

Pipeline overview of all certification flavors in one config file

The core of DCI certification is a pipeline file that manages detailed configurations for all certification tests. There are four primary sections that we’ll use for the certification: preflight_containers_to_certify for container certification, preflight_operators_to_certify for operator certification, dci_charts and helmchart_to_certify to initiate Helm chart verification, and cnf_to_certify to establish CNF certification projects in Connect. 

 

Preflight_containers_to_certify
Python

preflight_containers_to_certify:

  # run preflight check container tests

  - container_image: "quay.io/orga/image1@sha256:digest1"

  # run preflight check container tests

  # and submit the results to the existing cert project at Connect UI

  - container_image: "quay.io/orga/image2@sha256:digest2"

    pyxis_container_identifier: "ZZZZZZZZZZZZZZZZZZZZZZZ"

  # run preflight check container tests, 

  # create new certification project at Connect UI,

  # and submit the test results to this new project

  - container_image: "quay.io/orga/image3@sha256:digest3"

 

create_container_project: true

    short_description: "Here is the default 50+ characters image description"

  # run preflight check container tests, 

  # create new certification project at Connect UI,

  # submit the test results to this new project,

  # and attach the project to the existing Product Listings  

  - container_image: "quay.io/orga/image3@sha256:digest3"

    create_container_project: true

    short_description: "Here is the default 50+ characters image description"

    pyxis_product_lists:

       - "XXXXXXXXXXXXXXXXXXXXXXXX"    

       - "YYYYYYYYYYYYYYYYYYYYYYYY"

 

The preflight_containers_to_certify section automates the preflight check container tests. In the example configuration above, we cover four common use cases. More information can be found in our Red Hat Distributed CI blog and the documentation resource: preflight role and create_certification_project role in redhatci.ocp Ansible galaxy collection.

 

Preflight_operators_to_certify
Python

# List of operators to certify,

# you could provide many operators at once.

preflight_operators_to_certify:

  - bundle_image: "quay.io/rh-nfv-int/testpmd-operator-bundle:v0.2.9"

    # Mandatory for the connected environments.

    index_image: "quay.io/rh-nfv-int/nfv-example-cnf-catalog:v0.2.9"

    # Optional; provide it when you need to create

    # a new "Operator Bundle Image" and submit test results in it.

    create_operator_project: true

    # Optional; use it to open the certification PR automatically

    # in the certified-operators repository

    create_pr: true

    # Optional; use it to merge the certification PR automatically

    # in the certified-operators repository

    merge_pr: true
 

Similarly to standalone container certification, the preflight_containers_to_certify section, preflight_operators_to_certify handles running preflight check operator tests, submitting test results to an existing certification project in Connect or creating a new project and submitting test results there, as well as creating a pull request in the certified-operators repository. You can use all options at once or only part of the functionality. Detailed documentation can be found here.

dci_charts and helmchart_to_certify
Python

# run chart verifier tests and generate report.yaml

do_chart_verifier: true

partner_name: "MyNicePartnerName"

partner_email: "example@example.me"

dci_charts:

  - name: "my_nice_chart"

    chart_file: "path/to/my-nice-chart-1.2.3.tgz"

    deploy_chart: true

 

# create cert project for the helm chart

helmchart_to_certify:

  - repository: "https://github.com/orga/chartrepo"

    short_description: "Here is the default 50+ characters image description"

    chart_name: "my_nice_chart"

    create_helmchart_project: true

    pyxis_product_lists:

      - "YYYYYYYYYYYYYYYYYYYYYYYY"


While the same configuration manages both tests and the creation of certification projects for operators and containers, Helm charts have a separated approach: the dci_charts section runs the chart verifier tests, and the helmchart_to_certify section triggers the creation of the certification projects.

cnf_to_certify
Python

# create cnf cert project

cnf_to_certify:

  - cnf_name: "my-test23.5 OCP4.12.49"

    pyxis_product_lists:

      - "YYYYYYYYYYYYYYYYYYYYYYYY"
 

For CNF, we currently cannot automate much; we can only create the vendor-validated project in Connect.

 

Demo

Let's now consolidate everything into practical application. View a repository with an example setup for DCI-on-OPL certification, along with a demo illustrating the exact setup process.
 

Conclusion

Automation can improve, contribute, and bring further value to the certification experience. You will find more detailed information about our Certification workflows in our guides. If you have any questions, please contact the Partner Acceleration Desk.

Categories:

Training

Related products:

Red Hat OpenShift
Yanai Gonzalez photograph
Yanai Gonzalez
Engineer, Red Hat
Yanai Gonzalez is a Partner Engineer for the Certified Technology Ecosystem team at Red Hat. She has been with the team for over 2 years, working around application and operator certification for the Red Hat OpenShift Container Platform. She spends most of her days helping partners navigate through technical hurdles of certifying cloud native applications for OpenShift. Yanai lives in South Florida, and on the weekends enjoys spending time with her family and fishing.
TK
Tatiana Krishtop, PhD
Senior Software Engineer, Telco CI Lab
Tatiana works in a joint 50/50 position at Red Hat, spending half of her time as a software engineer and the other half as a reliability engineer. Her team owns an open-source tool called Distributed CI (DCI), which is a powerful and flexible CI platform written in Ansible. She also collaborates with Red Hat's Telco partners to help them use DCI on real-life Telco 5G workloads.
Pierre Blanc avatar
Pierre Blanc
Principal Software Engineer
Pierre Blanc works at Red Hat as a software engineer, with experience in IT infrastructure in a heterogeneous environment. He has always been a great open-source enthusiast and has contributed for many years. Pierre loves to participate in IT events worldwide, particularly in Montreal.