Red Hat Software Certification Workflow Guide

Ensure that your company profile is up-to-date. This information is published in the catalog along with your certified non-containerized application product.

To verify the information,

This feature allows you to perform the following functions:

To validate the functionality of your product on the Red Hat Enterprise Linux:

This feature allows you to either create a new product listing, or to attach the project to an existing RHEL product listing for your new project.

After completing all the steps, a green check mark appears beside the tiles to indicate that configuration is complete.

Prerequisites

Verify the functionality of your product on the target Red Hat platform, in addition to the specific certification testing requirements.If running your product on the targeted Red Hat platform results in a substandard experience then you must resolve the issues prior to certification.

The Red Hat Partner Acceleration Desk (PAD) is a Products and Technologies level partner help desk service that allows our (prospective) technology partners a central location to ask non-technical questions pertaining to Red Hat offerings, partner programs, product certification, engagement process, and so on.

See PAD - How to open & manage PAD cases, to open a PAD ticket.

Through the Partner Subscriptions program, Red Hat offers free, not-for-resale software subscriptions that you can use to validate your product on the target Red Hat platform. To request access to the program, follow the instructions on the Partner Subscriptions site.

You must construct your container images so that they meet the certification criteria and policy. For more details, see image content requirements.

Procedure

Follow these high-level steps to certify your containerized software:

Follow these high-level steps to run a certification test:

Certified container images are delivered to customers through the Red Hat Connect Image Registry, which you can then run on a supported Red Hat container platform. Your product and its images get listed on the Red Hat Container Catalog using the listing information that you provide.

Keep your company profile up-to-date. This information gets published in the Catalog along with your certified product.

To verify:

After completing all the steps, a green check mark appears beside the tiles to indicate that configuration is complete.

Export control questionnaire contains a series of questions through which the Red Hat legal team evaluates the export compliance by third-party vendors.

Partner’s legal representative must review and answer the questions. Red Hat takes approximately five business days to evaluate the responses and based on the responses Red Hat approves partner or declines partner or defers decision or requests more information.

NOTE - If you are using a version of UBI (Universal Base Image) to build your container image, you can host your image in a private repository. This allows you to skip the Export Compliance. This Export Compliance form is required only if you are hosting your images on the Red Hat Container Catalog.

Set up preflight locally and navigate to Submit your container for verification tile to submit the software certification test results.

You can either create a new product listing, or attach a project to an existing product listing.

Perform the steps outlined for the certification on-boarding:

To run the certification test:

When you complete all the certification checks successfully, you can submit the test results to Red Hat. You can turn on or off this result submission step depending on your individual goals. When the test results are submitted, it triggers the Red Hat infrastructure to automatically merge your pull request and publish your Operator.

The following diagram gives an overview of testing your Operator locally:

Figure 18.1. Overview of testing your Operator locally

Users must agree to the terms regarding the distribution of partner container images before they can publish any image.

Navigate to Accept the Red Hat Container Appendix tile and click Review Accepted Terms. Read the Red Hat Partner Connect Container Appendix document that displays for terms related to the distribution of container images.

Keep your company profile up-to-date. This information gets published in the Catalog along with your certified product.

To verify:

After completing all the steps, a green check mark appears beside the tiles to indicate that configuration is complete.

If you plan to publish your Operator bundle to Red Hat Marketplace, then navigate to Complete Red Hat Marketplace publication tasks tile and click Become a seller.

The Red Hat Marketplace onboarding team will contact you and work with you to approve this checklist item. If you experience any delay, please open a support ticket.

After completing the Pre-certification checklist, you can now go ahead and submit your Operator Bundle image. This is the last step in completing the certification for Operator Bundle image.

To run the Operator certification suite, navigate to the Test your operator bundle data and submit a pull request tile and click View Options. It displays two tabs to determine how to test and certify your operator.

This feature allows you to either create a new product listing or to attach the project to an existing OpenShift product listing for your new project.

This feature allows you to run the certification test locally and share the test results with the Red Hat certification team.

To validate the functionality of your specialized CNI or CSI operator:

Red Hat will review the results file you submitted and validate your specialized CNI or CSI operator. Upon successful validation, your operator will get approved and published.

Find the respective folder for your operator in the operators directory. Place the contents of your operator Bundle in this directory.

If the newly certifying operator does not have a subdirectory already under the operator’s parent directory then you have to create one.

Create a new directory under operators. The name of this directory should match your operator’s package name. For example, my-operator.

Recommended directory structure

The following example illustrates the recommended directory structure.

├── config.yaml
├── operators
    └── my-operator
        ├── v1.4.8
        │   ├── manifests
        │   │   ├── cache.example.com_my-operators.yaml
        │   │   ├── my-operator-controller-manager-metrics-service_v1_service.yaml
        │   │   ├── my-operator-manager-config_v1_configmap.yaml
        │   │   ├── my-operator-metrics-reader_rbac.authorization.k8s.io_v1_clusterrole.yaml
        │   │   └── my-operator.clusterserviceversion.yaml
        │   └── metadata
        │       └── annotations.yaml
        └── ci.yaml

Red Hat recommends using the automated process for installing the OpenShift Operator Pipeline. The automated process ensures the cluster is properly configured before executing the CI Pipeline. This process installs an operator to the cluster that helps you to automatically update all the CI Pipeline tasks without requiring any manual intervention. This process also supports multitenant scenarios in which you can test many operators iteratively within the same cluster.

Follow these steps to install the OpenShift Operator Pipeline through an Operator:

cat <<EOF> workspace-template.yml
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
EOF

Follow these steps to manually install the OpenShift Operator Pipeline:

export KUBECONFIG=/path/to/your/cluster/kubeconfig

oc adm new-project <my-project-name> # create the project
oc project <my-project-name> # switch into the project

oc create secret generic kubeconfig --from-file=kubeconfig=$KUBECONFIG

oc import-image certified-operator-index \
  --from=registry.redhat.io/redhat/certified-operator-index \
  --reference-policy local \
  --scheduled \
  --confirm \
  --all
oc import-image redhat-marketplace-index \
  --from=registry.redhat.io/redhat/redhat-marketplace-index \
  --reference-policy local \
  --scheduled \
  --confirm \
  --all

$git clone https://github.com/redhat-openshift-ecosystem/operator-pipelines
$cd operator-pipelines
$oc apply -R -f ansible/roles/operator-pipeline/templates/openshift/pipelines
$oc apply -R -f ansible/roles/operator-pipeline/templates/openshift/tasks

oc create secret generic github-api-token --from-literal GITHUB_TOKEN=<github token>

oc create secret generic pyxis-api-secret --from-literal pyxis_api_key=< API KEY >

oc create secret docker-registry registry-dockerconfig-secret \
    --docker-server=quay.io \
    --docker-username=<registry username> \
    --docker-password=<registry password> \
    --docker-email=<registry email>

Procedure

In a terminal window, run the following commands:

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (For example - operators/my-operator/1.2.8)

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --showlog

After running the command, the pipeline prompts you to provide additional parameters. Accept all the default values to finish executing the pipeline.

The following is set as default and doesn’t need to be explicitly included, but can be overridden if your kubeconfig secret is created under a different name.

--param kubeconfig_secret_name=kubeconfig \
--param kubeconfig_secret_key=kubeconfig

If you are running the ci pipeline on ppc64le and s390x architecture, edit the value of the parameter param pipeline_image from the default value quay.io/redhat-isv/operator-pipelines-images:released to quay.io/redhat-isv/operator-pipelines-images:multi-arch.

Troubleshooting

If you get a Permission Denied error when you are using the SSH URL, try the GITHUB HTTPS URL.

Prerequisites

Execute the instructions Enabling digest pinning.

Procedure

In a terminal window, run the following commands:

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --showlog

Troubleshooting

When you get an error - could not read Username for https://github.com, provide the SSH github URL for --param git_repo_url.

Prerequisites

Execute the instructions included under By using a private container registry.

Procedure

In a terminal window, run the following commands:

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>
REGISTRY=<your image registry.  ie: quay.io>
IMAGE_NAMESPACE=<namespace in the container registry>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param registry=$REGISTRY \
  --param image_namespace=$IMAGE_NAMESPACE \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --workspace name=registry-credentials,secret=registry-docker config-secret \
  --showlog \

Procedure

In a terminal window, execute the following commands:

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param upstream_repo_name=redhat-openshift-ecosystem/certified-operators \
  --param submit=true \
  --param env=prod \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --showlog

In a terminal window, execute the following commands:

Prerequisites

Execute the instructions included for:

Procedure

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param upstream_repo_name=red-hat-openshift-ecosystem/certified-operators \
  --param submit=true \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --showlog

Troubleshooting

When you get an error - could not read Username for https://github.com, provide the SSH github URL for --param git_repo_url.

In a terminal window, execute the following commands:

Prerequisites

Execute the instructions included for:

Procedure

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>
REGISTRY=<your image registry.  ie: quay.io>
IMAGE_NAMESPACE=<namespace in the container registry>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param registry=$REGISTRY \
  --param image_namespace=$IMAGE_NAMESPACE \
  --param upstream_repo_name=red hat-openshift-ecosystem/certified-operators \
  --param submit=true \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --workspace name=registry-credentials,secret=registry-docker config-secret \
  --showlog

In a terminal window, execute the following commands:

Prerequisites

Execute the instructions included for:

Procedure

GIT_REPO_URL=<Git URL to your certified-operators fork >
BUNDLE_PATH=<path to the bundle in the Git Repo> (ie: operators/my-operator/1.2.8)
GIT_USERNAME=<your github username>
GIT_EMAIL=<your github email address>
REGISTRY=<your image registry.  ie: quay.io>
IMAGE_NAMESPACE=<namespace in the container registry>

tkn pipeline start operator-ci-pipeline \
  --param git_repo_url=$GIT_REPO_URL \
  --param git_branch=main \
  --param bundle_path=$BUNDLE_PATH \
  --param env=prod \
  --param pin_digests=true \
  --param git_username=$GIT_USERNAME \
  --param git_email=$GIT_EMAIL \
  --param upstream_repo_name=red-hat-openshift-ecosystem/certified-operators \
  --param registry=$REGISTRY \
  --param image_namespace=$IMAGE_NAMESPACE \
  --param submit=true \
  --workspace name=pipeline,volumeClaimTemplateFile=templates/workspace-template.yml \
  --workspace name=ssh-dir,secret=github-ssh-credentials \
  --workspace name=registry-credentials,secret=registry-docker config-secret \
  --showlog

After a successful certification, the certified product gets listed on Red Hat Ecosystem Catalog.

Certified operators are listed in and consumed by customers through the embedded OpenShift operatorHub, providing them the ability to easily deploy and run your solution. Additionally, your product and operator image will be listed on the Red Hat Ecosystem Catalog.

Find the respective folder for your operator in the operators directory. Place the contents of your operator Bundle in this directory.

If the newly certifying operator does not have a subdirectory already under the operator’s parent directory then you have to create one.

Create a new directory under operators. The name of this directory should match your operator’s package name. For example, my-operator.

Recommended directory structure

The following example illustrates the recommended directory structure.

├── config.yaml
├── operators
    └── my-operator
        ├── v1.4.8
        │   ├── manifests
        │   │   ├── cache.example.com_my-operators.yaml
        │   │   ├── my-operator-controller-manager-metrics-service_v1_service.yaml
        │   │   ├── my-operator-manager-config_v1_configmap.yaml
        │   │   ├── my-operator-metrics-reader_rbac.authorization.k8s.io_v1_clusterrole.yaml
        │   │   └── my-operator.clusterserviceversion.yaml
        │   └── metadata
        │       └── annotations.yaml
        └── ci.yaml

Prerequisites

Verify the functionality of your product on the target Red Hat platform, in addition to the specific certification testing requirements.If running your product on the targeted Red Hat platform results in a substandard experience then you must resolve the issues prior to certification.

The Red Hat Partner Acceleration Desk (PAD) is a Products and Technologies level partner help desk service that allows our (prospective) technology partners a central location to ask non-technical questions about Red Hat offerings, partner programs, product certification, engagement process, and so on.

See PAD - How to open & manage PAD cases, to open a PAD ticket.

Through the Partner Subscriptions program, Red Hat offers free, not-for-resale software subscriptions that you can use to validate your product on the target Red Hat platform. To request access to the program, follow the instructions on the Partner Subscriptions site.

You must construct your container images so that they meet the certification criteria and policy. For more details, see image content requirements.

Procedure

Follow these high-level steps to certify your Helm chart:

Follow these high-level steps to run a certification test:

Certified helm charts are published on the Product Listings page of the Red Hat partner connect portal, which you can then run on a supported Red Hat container platform. Your product along with its Helm chart gets listed on the Red Hat Container Catalog using the listing information that you provide.

Keep your company profile up-to-date. This information gets published on the Red Hat Ecosystem Catalog along with your certified product.

To verify:

After creating your Helm chart project on the Red Hat partner connect you have to submit your Helm chart for verification.

To submit your Helm chart:

The pull request is reviewed by the Red Hat certification team. After successful verification, your Helm chart is published on the Red Hat Ecosystem Catalog.

This feature allows you to either create a new product listing, or to attach the project to an existing OpenShift product listing for your new project.

After completing all the steps, a green check mark appears beside the tiles to indicate that configuration is complete.

If you want to submit your Helm chart as a tarball, you can create a tarball of your Helm chart using the Helm package command and place it directly in the 0.1.0 directory.

For example, if your Helm chart is awesome for an organization acme

charts/partners/acme/awesome/0.1.0/awesome-0.1.0.tgz
charts/partners/acme/awesome/0.1.0/awesome-0.1.0.tgz.prov

If you want to submit your Helm chart in a directory, place your Helm chart in a directory with the chart source.

If you have signed the chart, place the providence file in the same directory. You can include a base64 encoded public key for the chart in the OWNERS file. When a base64 encoded public key is present, the key will be decoded and specified when the chart-verifier is used to create a report for the chart.

If the public key does not match the chart, the verifier report will include a check failure, and the pull request will end with an error.

If the public key matches with the chart and there are no other failures, a release will be created, which will include the tarball, the providence file, the public key file, and the generated report.

For example,

awesome-0.1.0.tgz
awesome-0.1.0.tgz.prov
awesome-0.1.0.tgz.key
report.yaml

If the OWNERS file does not include the public key, the chart verifier check is skipped and will not affect the outcome of the pull request. Further, the public key file will not be included in the release.

If the chart is a directory with the chart source, create a src directory to place the chart source.

For example,

A Path can be charts/partners/acme/awesome/0.1.0/src/

And the file structure can be

.
└── src
    ├── Chart.yaml
    ├── README.md
    ├── templates
    │   ├── deployment.yaml
    │   ├── _helpers.tpl
    │   ├── hpa.yaml
    │   ├── ingress.yaml
    │   ├── NOTES.txt
    │   ├── serviceaccount.yaml
    │   ├── service.yaml
    │   └── tests
    │       └── test-connection.yaml
    ├── values.schema.json
    └── values.yaml

Before submitting your report for certification, you can add a PGP public key to the chart verification report. Adding a PGP public key is optional. When you add it to your report, you can find your public key in the OWNERS file under your chart directory within your organization directory. The PGP public key is available in the publicPgpKey attribute. The value of this attribute must follow ASCII armor format.

When submitting a chart verification report without the chart, you can sign your report and save the signature in ASCII armor format.

For example,

gpg --sign --armor --detach-sign --output report.yaml.asc report.yaml

For submitting the chart verification report for a signed chart, when you provide a PGP public key to the chart verifier tool while generating the report, it includes a digest of the key along with the report.

Also, when you include a base64 encoded PGP public key to the OWNERS file, a check is made to confirm if the digest of the decoded key in the OWNERS file matches the key digest in the report.

When they do not match, the pull request fails. But if the key digest matches with the report and there are no other errors when processing the pull request, a release is generated containing the public key and the report.

For example,

awesome-0.1.0.tgz.key
report.yaml

You can sign the report and submit for verification. You can see a warning message on the console if the signature verification fails. For more information, see, 'For submitting a signed report' section of Submitting a Chart Verification Report without the Chart.

For a signed chart you must include a tarball and a providence file in addition to the report file. For more information, see, 'For submitting a report for a signed chart' section of Submitting a Chart Verification Report without the Chart.

Prerequisites

Ensure to check if your product meets the following requirements before proceeding with the certification process:

Verify the functionality of your product on the target Red Hat platform, in addition to the specific certification testing requirements. If running your product on the targeted Red Hat OpenShift Container platform results in a substandard experience, then you must resolve the issues prior to certification.

The Red Hat Partner Acceleration Desk (PAD) is a Products and Technologies level partner help desk service that allows our (prospective) technology partners a central location to ask non-technical questions pertaining to Red Hat offerings, partner programs, product certification, engagement process, and so on.

See PAD - How to open & manage PAD cases, to open a PAD ticket.

Through the Partner Subscriptions program, Red Hat offers free, not-for-resale software subscriptions that you can use to validate your product on the target Red Hat platform. To request access to the program, follow the instructions on the Partner Subscriptions site.

Procedure

Perform the steps outlined for the certification onboarding:

Perform the steps outlined for completing the checklist:

The Certified or Vendor Validated CNF project must be added as a component to your product’s Product Listing page on the Red Hat Partner Connect portal. Once published, your product listing is displayed on the Red Hat Ecosystem Catalog, by using the product information that you provide. You can publish both the Vendor Validated and Certified CNF products on the Red Hat Ecosystem Catalog with the respective labels.

This is an optional feature that allows you to certify your Vendor Validated project by using the Red Hat certification tool. For every Vendor Validated project, a new functional certification request will be created on the Red Hat Partner Certification portal. When you place a request for certification, your functional certification request will be processed by the CNF team for certification.

If you certify your Vendor Validated CNF project then it will be displayed on the Red Hat Ecosystem Catalog with the Certified label.

Prerequisites

Procedure

To certify your Vendor Validated CNF project, perform the following steps:

The Red Hat CNF certification team will review and verify the details of your CNF project. When the Red Hat CNF certification team identifies issues or violations in the recommended best practices with your CNF, joint discussions will ensue to find the remediation options and timeline. The team also considers temporary exceptions if there is a commitment to fix the issues with an identified release target or timeline. All exceptions will be documented and published in a KIE base article listing all non compliant items before CNF gets listed on the Red Hat Ecosystem Catalog but the technical details will remain private.

After successful verification by the Red Hat CNF certification team, your Vendor Validated CNF project will become certified, and will be automatically published on the Red Hat Ecosystem Catalog with the Certified label.