Deployment in Production Grade on Kubernetes Native

[yeplaa]

Type of question

My question is about best practices for installing and upgrading OLM in a Production environment

Question

What did you do?
Currently i deploy OLM based on "Customizing OLM installation" of https://github.com/operator-framework/operator-lifecycle-manager/blob/0.16.1/doc/install/install.md link. This allows me to overload my proxy registry as well as to choose the namespaces to deploy.
However, this installation mode corresponds more to a dev mode (binary go necessary in particular)

What did you expect to see?
For an installation on a Prod environment, the use of a packaging (like Helm or other) is necessary.
Also, a documentation to manage the version upgrades would be desirable. Do you have a recommendation on the method to follow for an installation in Prod? Do you have any features planned on this part?

Environment

• operator-lifecycle-manager version: 0.16.1

• Kubernetes version information: 1.18

• Kubernetes cluster kind:

Additional context
Add any other context about the question here.

[yeplaa]

Hi,

Have you some informations regarding my questions?

Thanks

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sathieu]

I think this is related to providing official Helm charts for OLM (#829). Unfortunately, it's currently marked wontfix.

[kevinrizza]

OLM is a package manager. From the maintainers perspectives, asking for helm charts for OLM is like asking for yum install dnf. Our expectation is that OLM is installed and upgraded manually with our install and upgrade scripts

[sathieu]

@kevinrizza Helm 3 doesn't require any component in the cluster anymore. To run helm install, you only need the helm binary.

Anyway, this is your right to make this decision, but for us this mean we'll get rid of OLM in the future (currently, we only need it for keycloak-operator which will be integrated in keycloak which already has helm charts).

[kevinrizza]

@sathieu when Helm had tiller as a component there was not a separate package manager used to install the on cluster component. If you want an officially released and packaged binary to install OLM you can use the operator-sdk to install it https://olm.operatorframework.io/docs/getting-started/

There's some work to provide a more seamless upgrade path rather than reusing the install command, but that would be the path to a better UX here rather than trying to install a package manager with another package manager

[acelinkio]

I do not really see the question being answered. How should this project be maintained in a production Kubernetes cluster?

The more apt comparison here is that olm should be the missing package manager that should be included kubernetes. That's the narrative taken by homebrew and they do everything in their power to make brew better than any alternative. However the community sees this as an Kebernetes extension, just like the other key components like storage/networking/ingress.

@kevinrizza Is there any chance user experience prioritization can be prioritized in the future? Shell script mentioned in #2969 would be nice beginning but does not drive a full lifecycle solution. Would be nice to have a longer term vision also described.