OKD Operator catalog?

[binnes]

As the community works on building RedHat operators, we need to decide how they should be made available to the community. Via the operatorhub community catalog or should we create an OKD catalog?

We need to consider the impact of adding RedHat operators into the community catalog, as this would result in duplicate catalog entries for OCP users, which may not be desirable?

If we do create an OKD catalog, then we need to have a governance process and automation to build and update the catalog and ensure quality of operators in the catalog. An option may be to limit the catalog to RedHat operators, so the OKD catalog would mirrot the RedHat catalog on OCP?

@LorbusChris @luigizuccarelli @sherine-k @JaimeMagiera we will add this to the agenda of the next OKD working group meeting to discuss.

[vrutkovs]

We need to consider the impact of adding RedHat operators into the community catalog, as this would result in duplicate catalog entries for OCP users, which may not be desirable?

Yes, we should avoid duplicates (including rebranded operators) to avoid confusion of OCP users.

If we do create an OKD catalog, then we need to have a governance process and automation to build and update the catalog and ensure quality of operators in the catalog.

We should have index prepared - https://github.com/redhat-openshift-ecosystem/okd-operators.

An option may be to limit the catalog to RedHat operators, so the OKD catalog would mirrot the RedHat catalog on OCP?

I think we should limit it to the team who are ready to accept bug reports. For instance, Red Hat Pipelines operators is almost identical to upstream (or so I heard), so I hope they won't have any problem helping us with issues, as the issues would be applicable to upstreams. Other teams might not be happy about an increased volume of reports from OKD users.

Another issue here is branding - do we want to keep the name, rename "Red Hat Logging" to "OKD Logging" operator or come up with a new one (i.e. Istio / Maistra)? This needs to be solved on a per-team basis.

In order to get this moving I think we should identify most popular / requested (lets check issues / OKD Telemetry) and start working with each specific team. Most easy candidate would be Pipelines - I remember Josef prepared an OKD bundle (which was rejected as it was not suitable for Community operators)

[darren-oxford]

Most definitely an OKD catalogue with the goal of eventually reaching parity with the RedHat operator Index.

Community editions of RedHat operators don't really have a place in the general community catalog. Not only does it create duplicate entries for OpenShift users, it also means two entries for OKD users with a developer key that enable the OpenShift catalogue. It also provides the option for an administrator that wants to limit the available operators to the core OKD set, rather than the huge community catalog, to disable the community operators catalog.

In terms of documentation it also makes life easier if we have a structure as similar as possible to OpenShift. The fewer differences between OpenShift and OKD, the lower the friction for people that are for example following blogs about OpenShift, they can simply substitute 'OpenShift operator' for 'OKD operator'.

When it comes to branding, there is no real option but to substitute RedHat & OpenShift for OKD branding. Why is this? It is to do with trademark law, RedHat & OpenShift are trademarks of RadHat. The purpose of a trademark is so that consumers can identify the source of a product or service. A trademark owner is obliged to protect that trademark by ensuring that products and services carrying their brand is under their control. In other words, either RedHat made it or the brand is licensed to a third party and the products overseen by RedHat.

Therefore, RedHat could in theory license the use of RedHat or OpenShift to the OKD community, however it would not be able to satisfy the requirement to oversee the products (software) being produced by the community. This will result in weakening of the trademark by virtue of what is known as naked licensing. Use of RedHat trademarks would therefore not be something that RedHat intellectual property attorneys would be comfortable with.

Not only does it have legal ramifications, it complicates support for RedHat. There is nothing for example stopping an OpenShift user activating the OKD catalog and then installing the OKD edition of a RedHat operator that we the community have made changes to, to accommodate Fedora CoreOS for example. With OKD branded versions of operators, it is immediately obvious to the RedHat support tech, that it is not the OpenShift supported version being used by their customer.

Disclaimer: I am not associated with RedHat, so this is my personal opinion. The information about branding is for guidance only, based on many years of personal experience with trademarks. I am not trademark attorney and this does not constitute legal advice.

[binnes]

What is the best way for interested community members to participate in this project?

Is the source of the redhat catalog in a public repo?

I have the community catalog : https://github.com/redhat-openshift-ecosystem/community-operators-prod.git
the certified operator catalog : https://github.com/redhat-openshift-ecosystem/certified-operators.git
and the market place catalog : https://github.com/redhat-openshift-ecosystem/redhat-marketplace-operators.git

Is there a proposed strategy on how we manage the catalog? Should we try to match the OCP catalog, or have our own processes, channel, operator update graph, etc. strategy (like we do for OKD)?

Ideally we should have a single source of truth (git repo(s)) that drives a (tekton) pipeline or pipelines to

• build or use pre-build container images for the app or service
• build the operator (bundle) for the app or service
• build the OKD catalog of operators

There is the project repo to build an operator (https://github.com/okd-project/okd-operator-pipeline.git) but there will need to be additional resources for the full OKD catalog solution

Do you have any suggestions or thoughts @LorbusChris @lmzuccarelli @sherine-k @luigizuccarelli and feedback to the issues raised by Vadim?

[lmzuccarelli]

The operator build pipeline was a POC built during "Shift Week" and would need some work to get it to "production ready".

@binnes - These are valid points that you bring up, we should set time aside to discuss and get consensus from the community.

[Lappihuan]

I am interested in the actual differences between the ocp and okd operators.
Is it sufficient to simply rebuild them from public source, as Cern does here?
or do you have to rebuild them inside UBI images?
i suspect this is a mix of legal and technical issues, but it is extremely confusing.

[darren-oxford]

In essence, yes, they just need rebuilding and adding to a public catalogue.

Run RedHat operators on your OKD cluster now.

It is in fact possible to run the RedHat operators on your OKD cluster if you have a free developer account, by obtaining a key and enabling the RedHat operators catalogue. Although a RedHat developer account does allow some limited use of RedHat products in production by an indvidual, I expect the majority of people running an OKD cluster in production are doing so in an educational institution or business environment of some kind. I have yet to come across any of the RedHat operators that do not work on OKD, so if you have a home lab set-up, simply get yourself a free developer account and enable the RedHat catalogue on your cluster.

Building RedHat operators

In theory, building a RedHat operator, simply involves building from the public source. There are however a few issues with this approach.

• Each OKD user will have to build their own, this is not only a huge duplication of effort, having everyone building their own, for some people it is beyond their capabilities, especially if they are more on the Ops side than Dev.
• In many cases building the operators is not entirely straightforward as things are set-up for the internal RedHat build systems so it often takes a fair amount of effort to figure out how to replace those parts.
• If an individual wishes to share their rebuilt operators with others, they would have to remove RedHat & OpenShift branding much like the clones of RHEL have to, in order remain legal.
• It is messy if users have to use multiple catalogue sources of unknown quality from multiple individuals.
• Operators rely on images to deploy the workload. In some cases these images may be in public repositories, many however, are in the RedHat registry that require a subscription key to access, so unable to deploy.

OKD Catalogue Effort

To address these issues what is needed are...

• A public 'OKD' catalogue that can be used as a substitute for the RedHat official catalogue. Preferably enabled by default in OKD so that installing operators is as straightforward as the OpenShift experience.
• Contributors that are willing to maintain one or more operator builds:-
  -- Working with RedHat project maintainers where necessary to find all the information necessary to build the operators.
  -- Monitoring and maintaining the build process for both the operator and container image dependencies.

The build process will require the substitution of the RedHat and OpenShift trademarks most likely with OKD branding (if done under the OKD community umbrella).

In my opinion, establishing an OKD catalog to start with and getting some OKD equivalents of the RedHat operators with an automated build pipeline is the first step, even if that catalogue contains only a few of the RedHat Operators to start with. The aim being to get enough people adopting an operator to eventually obtain close to parity with the official RedHat catalogue. We will probably always be missing some of the more obscure operators from the OKD catalogue, but some are foundational to using OKD really. The OpenShift Data Foundation for example is probably something that virtually every OKD cluster owner wants to use, unless they go to the trouble of using the upstream Rook Ceph project.

[Lappihuan]

@darren-oxford thank you very much for the detailed response!

so if we want to use operators for a PaaS product the developer subscription is a no go but building them from source is legal.

from what i gather there two repositories would be responsible for making okd operators a thing, could we just start adding "simpler" operators such as cluster-logging-operator?

• okd-operators
• okd-operator-pipeline

@lmzuccarelli you mention the above pipeline is not yet ready to use, what is missing from it?

[lmzuccarelli]

@Lappihuan - So the pipeline is really a POC, we took three operators that we built and used them as reference for the okd-operator-pipeline. The pipeline can be used but needs more verification , we need to address the story of branding (i.e icons etc). We tried both on kind (so entry to local dev is easy) and operate-first

We would be grateful if the community tries it out, makes recommendations, improves on what we have etc etc.
I hope that answers your question

[Lappihuan]

@lmzuccarelli thank you for the explanation.

The pipeline can be used but needs more verification , we need to address the story of branding (i.e icons etc). We tried both on kind (so entry to local dev is easy) and operate-first

since i'm very new to operators in general i'm sadly not yet fully grasping what would run locally on for example kind (or i'd assume CRC would also work) is it the pipeline itself or the installation of the built operators?

is this doc relevant for the okd-operato-pipelinte too?

i'd be up up to try and get the cluster-logging-operator working in there but probably need some time to get the whole concept behind it.

we need to address the story of branding (i.e icons etc).

wouldn't a okd-* prefix to all operators in the okd-operators repository be enough?
looking at #456 this would result in:

• okd-cluster-logging-operator
• okd-local-storage-operator
• okd-gitops-operator

this would prevent collision if someone has the redhat operators on his okd cluster but would also be predictable installing from the cli.

As for the icon there could be a "okd" watermark on whatever the original logo is, or if thats not legal just a okd icon to start with.

[bdlink]

Thanks, Darren, This whole issue is an active concern to the OKD working groups. Perhaps you could consider joining one of our meetings at 1700 UTC. On Feb 12, 2023, at 10:13 AM, Darren Grant ***@***.***> wrote:  CAUTION: This email originated from outside of BCIT. Do not click links or open attachments unless you recognize the sender and know the content is safe. In essence, yes, they just need rebuilding and adding to a public catalogue. Run RedHat operators on your OKD cluster now. It is in fact possible to run the RedHat operators on your OKD cluster if you have a free developer account, by obtaining a key and enabling the RedHat operators catalogue. Although a RedHat developer account does allow some limited use of RedHat products in production by an indvidual, I expect the majority of people running an OKD cluster in production are doing so in an educational institution or business environment of some kind. I have yet to come across any of the RedHat operators that do not work on OKD, so if you have a home lab set-up, simply get yourself a free developer account and enable the RedHat catalogue on your cluster. Building RedHat operators In theory, building a RedHat operator, simply involves building from the public source. There are however a few issues with this approach. * Each OKD user will have to build their own, this is not only a huge duplication of effort, having everyone building their own, for some people it is beyond their capabilities, especially if they are more on the Ops side than Dev. * In many cases building the operators is not entirely straightforward as things are set-up for the internal RedHat build systems so it often takes a fair amount of effort to figure out how to replace those parts. * If an individual wishes to share their rebuilt operators with others, they would have to remove RedHat & OpenShift branding much like the clones of RHEL have to, in order remain legal. * It is messy if users have to use multiple catalogue sources of unknown quality from multiple individuals. * Operators rely on images to deploy the workload. In some cases these images may be in public repositories, many however, are in the RedHat registry that require a subscription key to access, so unable to deploy. OKD Catalogue Effort To address these issues what is needed are... * A public 'OKD' catalogue that can be used as a substitute for the RedHat official catalogue. Preferably enabled by default in OKD so that installing operators is as straightforward as the OpenShift experience. * Contributors that are willing to maintain one or more operator builds:- -- Working with RedHat project maintainers where necessary to find all the information necessary to build the operators. -- Monitoring and maintaining the build process for both the operator and container image dependencies. The build process will require the substitution of the RedHat and OpenShift trademarks most likely with OKD branding (if done under the OKD community umbrella). In my opinion, establishing an OKD catalog to start with and getting some OKD equivalents of the RedHat operators with an automated build pipeline is the first step, even if that catalogue contains only a few of the RedHat Operators to start with. The aim being to get enough people adopting an operator to eventually obtain close to parity with the official RedHat catalogue. We will probably always be missing some of the more obscure operators from the OKD catalogue, but some are foundational to using OKD really. The OpenShift Data Foundation for example is probably something that virtually every OKD cluster owner wants to use, unless they go to the trouble of using the upstream Rook Ceph project. — Reply to this email directly, view it on GitHub<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fokd-project%2Fokd%2Fdiscussions%2F1387%23discussioncomment-4950533&data=05%7C01%7Cbruce_link%40bcit.ca%7Cd0b5f05b05f744985f2308db0d24c5ca%7C8322cefd0a4c4e2cbde5b17933e7b00f%7C0%7C0%7C638118223810963112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=AY%2F5fFcIu4Gdrl4GOyzy8sIwE8pBfwly1lbgYH8C6WU%3D&reserved=0>, or unsubscribe<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAEBGE4EKB5TLU6AHJPDFC3WXER2VANCNFSM6AAAAAARUJS7RE&data=05%7C01%7Cbruce_link%40bcit.ca%7Cd0b5f05b05f744985f2308db0d24c5ca%7C8322cefd0a4c4e2cbde5b17933e7b00f%7C0%7C0%7C638118223810963112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wXsnK%2Fcw2VZBYA%2FjodA0vc7JP1Kj4USjcd3TNqNCwjc%3D&reserved=0>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>