Certified Operator Build Guide
Search…
Certified Operator Build Guide
Introduction
What is an Operator?
Pre-Requisites
Helm Operators
Building a Helm Operator
Ansible Operators
Building an Ansible Operator
Golang Operator Gotcha's
Writing to the Status Subresource
OpenShift Deployment
Operator Metadata
Installing an OpenShift Environment
Deploying onto OpenShift
Troubleshooting and Resources
Creating an Ansible Role From a Helm Chart
Security Context Constraints
Connect Metadata Test Results
Red Hat Marketplace Requirements
Appendix
What if I've already published a Community Operator?
Community Operators
AWS OpenShift 4 Cluster Quick Start Guide
Using Third Party Network Operators with OpenShift
Bundle Maintenance After Migration
Frequently Asked Questions (FAQ)
Multi-Arch Operator Certification
Powered By GitBook
Frequently Asked Questions (FAQ)
The recommended version is the 1.0.0+ this brings significant changes but it will allow you to build the bundle images using the new format.

What happens to the previous operator project? Do we just upload the actual operator image there?

That's correct. The previous operator project holds the operator container image. Not the bundle image. You will need to continue to update the operator image through that project, and the bundle metadata image to the new project.

How is a new version released? Just uploading and publishing the image in the bundle project is enough?

Once you update your operator and are ready for a new version, you will need to update the operator image and once that is published you can submit the bundle image. A new version is released when you push your metadata bundle image to the bundle project. Once you publish the Bundle Image it will take about 1-2 hours for the new version to show up on embedded OperatorHub.
The upgrade path remains the same. The CSV behaves the same way. The difference is that now each new version will have its metadata registered in a container image too. So the operator container image itself remains the same way. The metadata is what changes. It's now delivered per version in a single container image as a metadata storage. More information regarding the certification workflow and the updated files structure can be found here: Bundle Maintenance After Migration.

What labels should be used for future OpenShift releases? Currently I see only 4.5 and 4.6

The label that says 4.5 implicitly takes care of all previous versions of OpenShift. The newer labels from 4.7 and beyond will be automatically handled in the backend process. In the future we will publish new documentation in case you don't want your operator to show up in a specific OpenShift version.
Appendix - Previous
Bundle Maintenance After Migration
Next - Appendix
Multi-Arch Operator Certification
Last modified 1mo ago
Copy link
Contents
What is the recommended version for Operator-SDK?
What happens to the previous operator project? Do we just upload the actual operator image there?
How is a new version released? Just uploading and publishing the image in the bundle project is enough?
What labels should be used for future OpenShift releases? Currently I see only 4.5 and 4.6