File-based catalog (FBC) support is live!

[Allda]

Hello community!

I am glad to announce that we just released support for a File-based catalog (FBC) for OpenShift operators in this repository.

We have heard your feedback from the last couple of months and realized the current operator workflow has certain limitations and doesn’t allow full operator manipulation.

I am sure not all of you are familiar with what FBC is and its benefits so here are a couple of use cases that you might find useful.

Use cases supported by FBC workflow:

• Direct access to operator update graph
• Bundle channel promotion
• Modification and removal of bundles
• Catalog deprecation feature
• Independent operator bundle and catalog release cycle

More information about FBC can be found in the official upstream documentation.

• https://olm.operatorframework.io/docs/reference/file-based-catalogs/
• https://olm.operatorframework.io/docs/reference/catalog-templates/

Where to start?

We prepared documentation with 2 major starting points that cover FBC onboarding. Based on your current status you can follow one of them.

• I have an existing operator that I would like to convert
• I am starting a new operator and I would like to use all FBC benefits

We are also going to record a short demo later this week to show you the onboarding process. Subscribe to this thread to get more information and updates.

We are looking for your onboarding contribution. In case you need any help with onboarding or have any questions or feedback please reach out to our slack channel #forum-community-operators

Thank you,
The Collective team, Red Hat

[Allda]

@ack-bot @jwendell @mvalarh @openshift-service-mesh-bot @maistra-bot @quay-devel @mbaldessari @acornett21 @gl-distribution-oc @opentelemetrybot @konveyor-release-bot @codeflare-machine-account @shefali-malhotra @streamnativebot @vmuzikar @ndmspc @jmazzitelli @VaishnaviHire @ggeorgiev-gitlab @mkuznyetsov @raffaelespazzoli @acm-canary-bot @DanielePalaia @dt-team-kubernetes @mmontes11 @suhanime @zhiweiyin318 @che-incubator-bot @dlom @ryanemerson @jotak @gusfcarvalho @christophd @wallrj @spilchen @NissesSenap @scholzj @openshift-edge-bot @2uasimojo @pavolloffay @djzager @selvamt94 @devOpsHelm @maskarb @moolen @lbroudoux @sabre1041 @hco-bot @eguzki @iamabhishek-dubey @becash143 @spolti @tolusha @piyush-nimbalkar @abutcher

[Allda]

Here is the introduction video with a step-by-step process for onboarding the FBC. Go check that out!

https://www.youtube.com/watch?v=6yOyw0LhZ3w

And here is the list of PR with usecases mentioned in the video:

• Existing operator conversion
• Operator removal
• Operator removal from single ocp version
• Channel rename
• Conversion to SemVer template
• Simple bundle release with FBC workflow

[2uasimojo]

We're being told that FBC will become mandatory in February, but that it is not and will not be supported by the upstream catalog.

We produce bundles for both. We have tooling that Just Works today. This discussion thread just went from, "hey, check out this thing you might care about, in your own time," to not just, "you're going to have to change over," but, "you're going to have to change over and maintain two separate things now."

Not okay.

If you are on this discussion, and own a repository that publishes to both catalogs, and are similarly affected, please weigh in so we can find a better path forward.

[pursultani]

While we appreciate the potential benefits of FBC, we have some significant concerns about this change and its impact on our current workflows.

GitLab currently publishes to OperatorHub as well as RedHat Certified and Community Operators multiple times per month for each GitLab patch release. We have invested considerable time and resources in developing tooling that supports this process seamlessly. The current system works efficiently for us, allowing us to maintain a smooth and frequent release cycle across multiple catalogs.

The transition to FBC, especially with the February mandatory timeline, poses several challenges for us:

1. Dual maintenance: As mentioned in the previous comment, this change would require us to maintain two separate systems - one for the upstream catalog and another for FBC. This duplicates our efforts and increases complexity in our release process.
2. Timeline constraints: The proposed timeline for mandatory transition is not something we can easily prioritize at the moment. Our current roadmap and resource allocation don't allow for a quick pivot to a new system, especially one that requires significant changes to our established workflows.
3. Tooling investment: We've made substantial investments in our current tooling. A forced transition to FBC would potentially render much of this investment obsolete, requiring additional time and resources to develop new tools or significantly modify existing ones.
4. Operational impact: The frequent publishing we currently maintain might be disrupted during and after the transition, potentially affecting our ability to deliver timely updates to our users.

While we understand the intent behind FBC and its potential long-term benefits, the immediate impact on our operations is concerning. We would appreciate further discussion on this matter, particularly regarding:

• A more flexible timeline for transition
• Support for maintaining compatibility with both systems during a longer transition period
• Guidance on minimizing the impact on existing tooling and workflows

We believe that many other organizations publishing to multiple catalogs may face similar challenges. We hope that by raising these concerns, we can work together to find a path forward that addresses the needs of all stakeholders in the OpenShift operator ecosystem.

[ryanemerson]

We're being told that FBC will become mandatory in February, but that it is not and will not be supported by the upstream catalog.

This is my main concern. Having distinct processes adds additional overhead to our release and maintenance efforts. Can anybody provide details of why the upstream can't/won't also move to FBC?

[Allda]

Hey folks, the FBC is not going to be mandatory. We originally thought that we would make it mandatory for new operators but decided to make it optional after getting user feedback.

You can keep producing the operator in its current form and it will be supported going forward. However, the "older" format is not very flexible and doesn't allow users to make changes in the update graph nor remove existing bundles. Since this is a community project and our team has a limited capacity any request for manually updating operators for non-fbc operators will be denied and migration to FBC would be a suggested option.

We are also considering adding an FBC for the k8s operator repository. At this point, both of these repositories rely on completely different solutions so adding support to k8s won't be an easy job. We are currently evaluating the benefits and trying to estimate the size of this effort.

Once we have more information we will get back to you.

Ales