Search

Chapter 3. Products managed by an Operator

download PDF

Operators must be capable of deploying your software product on Red Hat OpenShift, using Operator Lifecycle Manager (OLM) from the targeted Red Hat OpenShift releases.

Warning

If any specific hardware requirements are essential to run your certified operator, Red Hat recommends informing your customers by listing all the requirements on your product’s system requirement page and linking it to your product page on the Red Hat Ecosystem catalog.

3.1. Operator requirements

RequirementJustification

The Operator bundle must successfully pass the Operator SDK bundle validation.

Red Hat recommends the usage of the SDK to create the Operator, to ensure that the format is correct.

To ensure correct format and compatibility with Operator Lifecycle Manager (OLM).

The Operator must update the status field of each custom resource (CR).

To ensure that users can determine the running state of the CR and identify potential failures.

The cluster service version (CSV) in the Operator bundle must include all the fields indicated in Required CSV fields as well as the following required fields under metadata.annotations:

categories
Comma-separated string of the community-operators/categories list that applies to this product.
description
Short description of the Operator.
containerImage
The full location (registry, repository, name, and tag) of the Operator image.
createdAt
A rough (to the day) timestamp of the creation of the Operator image.
support
Name of your company, as the vendor supporting this product.
operators.openshift.io/valid-subscription
Information about subscriptions or licenses that are required to use the product, as free form text.
features.operators.openshift.io/disconnected
Specify whether an Operator leverages the spec.relatedImages CSV field and can run without an internet connection by referring to any related image by its digest. Valid values are "true" or "false".
features.operators.openshift.io/fips-compliant
Specify whether an Operator accepts the Federal Information Processing Standards (FIPS) configuration of the underlying platform and works on nodes that are booted into FIPS mode. In this mode, the Operator and any workloads it manages (operands) are solely calling the Red Hat Enterprise Linux (RHEL) cryptographic library submitted for FIPS-140 validation. Valid values are "true" or "false".
features.operators.openshift.io/proxy-aware
Specify whether an Operator supports running on a cluster behind a proxy by accepting the standard HTTP_PROXY and HTTPS_PROXY proxy environment variables. If applicable, the Operator passes this information to the workload it manages (operands). Valid values are "true" or "false".
features.operators.openshift.io/tls-profiles
Specify whether an Operator implements well-known tunables to modify the TLS cipher suite used by the Operator and, if applicable, any of the workloads it manages (operands). Valid values are "true" or "false".
features.operators.openshift.io/token-auth-aws
Specify whether an Operator supports configuration for tokenzied authentication with AWS APIs via AWS Secure Token Service (STS) by using the Cloud Credential Operator (CCO). Valid values are "true" or "false".
features.operators.openshift.io/token-auth-azure
Specify whether an Operator supports configuration for tokenzied authentication with Microsoft Azure APIs via Azure Managed Identity by using the Cloud Credential Operator (CCO). Valid values are "true" or "false".
features.operators.openshift.io/token-auth-gcp
Specify whether an Operator supports configuration for tokenzied authentication with Google Cloud APIs via Google Cloud Platform (GCP) Workload Identity Foundation (WIF) by using the Cloud Credential Operator (CCO). Valid values are "true" or "false".

Other optional annotations can be defined as well, such as for the following Kubernetes plugins:

features.operators.openshift.io/cnf
Specify whether an Operator provides a Cloud-Native Network Function (CNF) Kubernetes plugin.
features.operators.openshift.io/cni
Specify whether an Operator provides a Container Network Interface (CNI) Kubernetes plugin.
features.operators.openshift.io/csi
Specify whether an Operator provides a Container Storage Interface (CSI) Kubernetes plugin.

For more information about required annotations, optional annotations, and example usage in CSVs, see Operator metadata annotations.

Provides detailed information about the product managed by this Operator to users and support organizations.

The Operator bundle must indicate the minor versions of OpenShift that the target product supports by setting the com.redhat.openshift.versions annotation. For details on the syntax, see Controlling Operator compatibility with OpenShift Container Platform versions.

The version range must include one or more actively supported RHOCP versions, that are in the Full Suport or Maintenance Support life cycle phases.

Any Red Hat OpenShift releases that are included in the range but are no longer supported are not considered certification targets. Publication of the Operator for those releases will be handled on a best-effort-basis.

The version range can include a future release version of RHOCP. In that case, the Operator will be listed as certified after that version becomes generally available.

Informs users about the Red Hat OpenShift versions supported by the partner for this Operator, while ensuring that customers can deploy it in an OpenShift environment that can be supported by Red Hat.

The version details are used to determine which version-specific Operator catalog indexes must be updated.

The Operator must not use any APIs that are not present in all versions of Red Hat OpenShift included in this range.

Ensures that any APIs used are available in the targeted versions.

The CSV in the Operator bundle must indicate all the CRDs Owned by the Operator.

To ensure adequate tracking and management of CRD lifecycle.

The CSV in the Operator bundle must indicate all the container images needed to perform its function, using the spec.relatedImages field.

To correctly identify all the dependencies.

The Operator name must be different from any other Operator name already published in the Community, Certified, and Red Hat catalogs.

To avoid name conflicts.

3.2. Operand requirements

Each container managed by the Operator (Operands) must be certified by Red Hat and must fulfill the requirements listed in the Requirements for container images section.

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.