Open briantopping opened 4 years ago
sbose78
commented
4 years ago Thank you @briantopping for the proposal.
Are you proposing that Argo CD recognize OLM manifest directories present in a Github Repository?
As an example:
For RepoURL =
https://github.com/operator-framework/community-operators , and
Path = community-operators/cockroachdb/cockroachdb.package.yaml
We should support an ApplicationSourceOLM with configuration attributes like:
briantopping
commented
4 years ago Hi @sbose78, thank you for your consideration.
I believe you will want to inventory the CatalogSource CRs on a machine, which are similar to installed Helm repositories (operatorhub.io is an example). From there, the popup for possible packages could be populated with the contents of that catalog.
Each CatalogSource will have policies for operator acceptance. Argo is in operatorhub.io, so someone on your team will know it does not allow operators that grant inappropriate permissions or access to all namespaces. I believe this is good security hygiene, but your proposal to recognize OLM manifest directories present in a Github Repository may have strong benefits for different use cases. I just think the permissions should be such that administrators can choose to control the import of operators and CRs from sources they have not audited.
Once an application expresses a dependency on an operator, it can apply CRs for the lifecycle management of the software that it depends on (for instance, ELK).
sbose78
commented
4 years ago Hi!
I was trying to draw the experience in mind in a simplified way:
1) Are you suggesting the user would provide the image that's typically used in the CatalogSource's spec.image
2) Argo would inspect the CatalogSource index image to list all available operators that could be installed
3) On confirmation by the user, a Subscription is created behind the scenes ?
How does this look ?
Regarding having operators operate within boundaries, we could use some of the OLM's policy management guidelines: https://docs.openshift.com/container-platform/4.5/operators/olm-creating-policy.html
Summary
ArgoCD currently supports repository sources from Git and Helm. A new source that could serve from OLM would be similarly useful. For those not familiar, OLM stands for "Operator Lifecycle Manager" and is essentially a package manager for operators. When installed on a cluster, OLM provides the behaviors that allow the metadata in catalogs such as operatorhub.io to provide automated maintenance of operators, including automatic version upgrades. Note that operator upgrades do not automatically upgrade deployed application versions, though a newer operator may reconcile those applications differently such as to more fully secure an existing version.
Motivation
There are a lot of functional similarities between an operator that is distributed as a Helm 3 compatible chart and one distributed as an OLM package. If every operator was packaged with Helm, this proposal would arguably be less valuable. Unfortunately, that's often not the case. OLM also provides minor benefits to operator deployment as it is not a static template tool like Helm is. It is worth comparing and contrasting operators installed with Helm vs those installed with OLM.
Proposal
The OpenShift OKB console could provide a UX template for what Argo could do as a OLM frontend. Such support would be unique for bare k8s clusters, potentially leading to additional adoption.