This is a follow up to the discussion on Slack. I would like to start with thanking RedHat for investing in what I hope will be a great community resource.
I am concerned about the very strong ties between Operator Lifecycle Manager and OperatorHub/this repo. OLM is an interesting and powerful tool that definitely answers a need for folks at the top end of the complexity spectrum (such as big, multi-tenant clusters). However the operator pattern has been embraced across the entire Kubernetes community, including many places where that level of complexity is not required. Additionally OLM is a fairly opinionated tool, for example it requires that CRDs be available as YAML and managed outside of the operator vs. the increasing pattern of having operators self-register their CRDs. For some operators, a Helm chart is an entirely reasonable deployment mechanism, even if this does not address all of the same edge cases that OLM does. Beyond the complexity issues (OLM is a fairly complex suite of metadata files), there is also the problem that every update to the OLM manifests (I think) has to go through this repo which means it can be blocked on getting signoff from a completely unrelated project. I'm sure the folks on this repo will do their best, but that seems like a solution that will not scale to larger community uptake.
As a more general statement, I would like to take a few steps back and try to separate out the (very good) RedHat operator stack from the broader community use of the term. I feel that RedHat is perceived by the community, or at least by me, as trying to exert some level of ownership over the term "operator" as the originators of that term and pattern, however the community has grown far beyond those specific initial meanings and I think OperatorHub should reflect that.
That said, some level of metadata is clearly needed to usefully operate a website like this. I think maybe a good path forward would be to identify some limited subset of the OLM metadata that can act as a more general purpose operator metadata, without the specifics of installation and configuration management that OLM implements. Off the top of my head, I think maybe an improved "channels" function that allows drawing the operator manifests directly from their own repository (or other HTTP server), and using a stripped down version of the existing ClusterServiceVersion with:
Name
Version
Description
Keywords
Maturity (debatable)
Maintainers
Links
Icon
To that we would need to add fields to describe the installation. In the OLM case, it would use the remaining metadata. For Helm, we could describe the Helm repository and chart name, possibly with some optional info about the chart values. For plain manifests, it could have a link to the manifest with a description.
I would love to see this website live up to its tag line of "a new home for the Kubernetes community to share Operators", and I think an important step will be to make OLM only one of many options for installation and management that have been embraced by our community.
Copied from: https://github.com/operator-framework/community-operators/issues/150
This is a follow up to the discussion on Slack. I would like to start with thanking RedHat for investing in what I hope will be a great community resource.
I am concerned about the very strong ties between Operator Lifecycle Manager and OperatorHub/this repo. OLM is an interesting and powerful tool that definitely answers a need for folks at the top end of the complexity spectrum (such as big, multi-tenant clusters). However the operator pattern has been embraced across the entire Kubernetes community, including many places where that level of complexity is not required. Additionally OLM is a fairly opinionated tool, for example it requires that CRDs be available as YAML and managed outside of the operator vs. the increasing pattern of having operators self-register their CRDs. For some operators, a Helm chart is an entirely reasonable deployment mechanism, even if this does not address all of the same edge cases that OLM does. Beyond the complexity issues (OLM is a fairly complex suite of metadata files), there is also the problem that every update to the OLM manifests (I think) has to go through this repo which means it can be blocked on getting signoff from a completely unrelated project. I'm sure the folks on this repo will do their best, but that seems like a solution that will not scale to larger community uptake.
As a more general statement, I would like to take a few steps back and try to separate out the (very good) RedHat operator stack from the broader community use of the term. I feel that RedHat is perceived by the community, or at least by me, as trying to exert some level of ownership over the term "operator" as the originators of that term and pattern, however the community has grown far beyond those specific initial meanings and I think OperatorHub should reflect that.
That said, some level of metadata is clearly needed to usefully operate a website like this. I think maybe a good path forward would be to identify some limited subset of the OLM metadata that can act as a more general purpose operator metadata, without the specifics of installation and configuration management that OLM implements. Off the top of my head, I think maybe an improved "channels" function that allows drawing the operator manifests directly from their own repository (or other HTTP server), and using a stripped down version of the existing ClusterServiceVersion with:
Name Version Description Keywords Maturity (debatable) Maintainers Links Icon To that we would need to add fields to describe the installation. In the OLM case, it would use the remaining metadata. For Helm, we could describe the Helm repository and chart name, possibly with some optional info about the chart values. For plain manifests, it could have a link to the manifest with a description.
I would love to see this website live up to its tag line of "a new home for the Kubernetes community to share Operators", and I think an important step will be to make OLM only one of many options for installation and management that have been embraced by our community.