---
description: >-
  This page defines the terminology used throughout this section for further
  clarity.
---

# Glossary of Terms

<table><thead><tr><th width="150">Term</th><th>Definition</th></tr></thead><tbody><tr><td><strong>Red Hat Partner Connect</strong></td><td>The Red Hat Technology Partner portal website resolved by <a href="https://connect.redhat.com">connect.redhat.com</a>.</td></tr><tr><td><strong>Red Hat Ecosystem Catalog</strong></td><td>The official Red Hat software catalog for containers, operators and other software from both Red Hat and Technology Partners, as resolved by <a href="https://catalog.redhat.com">catalog.redhat.com</a>.</td></tr><tr><td><strong>Red Hat Container Catalog / RHCC Registry</strong></td><td>Often abbreviated as the RHCC registry or simply RHCC, this is the container image registry provided by Red Hat for hosting partner-provided, certified container images. It is resolved by <a href="https://registry.connect.redhat.com">registry.connect.redhat.com</a>.</td></tr><tr><td><strong>External Registry</strong></td><td>This is any container image registry that is not hosted by Red Hat, such as <a href="https://quay.io">quay.io</a>, docker.io or any other third party or private image registry.</td></tr><tr><td><strong>Scan Registry</strong></td><td>The scan registry is the Red Hat internal registry or staging area used during the container image scanning process. It is kept behind the scenes, and is not a point of user interaction for multi-arch images.</td></tr><tr><td><strong>Project</strong></td><td>A project is analogous to a container image repository and exists within the context of the Red Hat Partner Connect website. You typically need a project created for every container image that you intend to certify.</td></tr><tr><td><strong>Operator</strong></td><td>In this section, the term <em>operator</em> generally refers to the operator's container (or controller) image.</td></tr><tr><td><strong>Operand</strong></td><td>The <em>operand</em> is the operator's workload container image. There can be, and often are multiple operand images for any particular operator.</td></tr><tr><td><strong>Bundle</strong></td><td>The directory containing the operator deployment <code>manifests/</code> and <code>metadata/</code> directories, and optionally the <code>tests/</code> directory for additional custom tests. It is usually named for the release version it deploys (such as <code>1.0.0/</code>). This is what gets <a href="https://github.com/redhat-openshift-ecosystem/certified-operators-preprod">submitted to GitHub</a> per the operator release workflow.</td></tr><tr><td><strong>Digest</strong></td><td>The <a href="https://csrc.nist.gov/glossary/term/secure_hash_algorithm">SHA 256</a> digest of a particular container image (which is actually the digest of the manifest for that image).</td></tr><tr><td><strong>Manifest</strong></td><td>The metadata or descriptor file of a container image. This contains the labels applied when the image was created, a list of the layers within the image along with their respective digests, and other descriptive information. This file should conform to the <a href="https://github.com/opencontainers/image-spec/blob/main/manifest.md">OCI specification</a>.</td></tr><tr><td><strong>Manifest List</strong></td><td>This is a type of manifest which is nothing more than a list of other manifests (by their respective digest and architecture). The list usually contains one manifest for each supported CPU architecture. The intent is to support a single <em>multi-arch</em> image that could match the corresponding architecture of the machine it's being run on. This is also defined in the <a href="https://github.com/opencontainers/image-spec/blob/main/image-index.md">OCI spec</a>.</td></tr></tbody></table>

{% hint style="info" %}
Did we miss anything? If you find a confusing term anywhere in this section, please let us know and we'll get it added to the list above.
{% endhint %}
