This repo is the canonical source for Kubernetes Operators that appear on OpenShift Container Platform and OKD.
NOTE The index catalog registry.redhat.io/redhat/redhat-operator-index:v<OCP Version> is built from this repository and it is
consumed by Openshift and OKD to create their sources and built their catalog. To know more about how
Openshift catalog are built see the documentation.
We would love to see your Operator added to this collection. We currently use automated vetting via continuous integration plus manual review to curate a list of high-quality, well-documented Operators. If you are new to Kubernetes Operators start here.
If you have an existing Operator read our contribution guidelines on how to package. Then the community operator pipeline will be triggered to test your Operator and merge a Pull Request.
- Prerequisites
- Where to place operator
- Creating pull request (PR)
- Accepted Bundle Format
- Operator Publishing / Review settings
- OKD/OpenShift Catalogs criteria and options
Refer to the Community operator pipeline documentation .
Some APIs versions are deprecated and are OR will no longer be served on the Kubernetes version
1.22/1.25/1.26 and consequently on vendors like Openshift 4.9/4.12/4.13.
What does it mean for you?
Operator bundle versions using the removed APIs can not work successfully from the respective releases.
Therefore, it is recommended to check if your solutions are failing in these scenarios to stop using these versions
OR by setting the "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<OCP version>"}]'
to block cluster admins upgrades when they have Operator versions installed that can not
work well in OCP versions higher than the value informed. Also, by defining a valid OCP range via the annotation com.redhat.openshift.versions
into the metadata/annotations.yaml for our solution does not end up shipped on OCP/OKD versions where it cannot be installed.
WARNING:
olm.maxOpenShiftVersionshould ONLY be used if you are 100% sure that your Operator bundle version cannot work in upper releases. Otherwise, you might provide a bad user experience. Be aware that cluster admins will be unable to upgrade their clusters with your solution installed. Then, suppose you do not provide any upper version and a valid upgrade path for those who have your Operator installed be able to upgrade it and consequently be allowed to upgrade their cluster version (i.e from OCP 4.10 to 4.11). In that case, cluster admins might choose to uninstall your Operator and no longer use it so that they can move forward and upgrade their cluster version without it.
Please, make sure you check the following announcements:
- How to deal with removal of v1beta1 CRD removals in Kubernetes 1.22 / OpenShift 4.9
- Kubernetes API removals on 1.25/1.26 and Openshift 4.12/4.13 might impact your Operator. How to deal with it?
Use the issue tracker in this repository to report bugs.