Glossary of Terms

This page defines the terminology used throughout this section for further clarity.

Term	Definition
Red Hat Partner Connect	The Red Hat Technology Partner portal website resolved by connect.redhat.com.
Red Hat Ecosystem Catalog	The official Red Hat software catalog for containers, operators and other software from both Red Hat and Technology Partners, as resolved by catalog.redhat.com.
Red Hat Container Catalog / RHCC Registry	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 registry.connect.redhat.com.
External Registry	This is any container image registry that is not hosted by Red Hat, such as quay.io, docker.io or any other third party or private image registry.
Scan Registry	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.
Project	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.
Operator	In this section, the term operator generally refers to the operator's container (or controller) image.
Operand	The operand is the operator's workload container image. There can be, and often are multiple operand images for any particular operator.
Bundle	The directory containing the operator deployment manifests/ and metadata/ directories, and optionally the tests/ directory for additional custom tests. It is usually named for the release version it deploys (such as 1.0.0/). This is what gets submitted to GitHub per the operator release workflow.
Digest	The SHA 256 digest of a particular container image (which is actually the digest of the manifest for that image).
Manifest	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 OCI specification.
Manifest List	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 multi-arch image that could match the corresponding architecture of the machine it's being run on. This is also defined in the OCI spec.

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.