Operator Controller Should Provide a Standard Install Process

[acornett21]

Today the install is done from yamls from the the release pages, which is less the ideal for end users. We should mimic the install process of OLMv0 (as far as steps go, the mechanism could be different). Sample process below:

1. Install dependencies
2. Install operator-controller
3. Install the same catalog from OperatorHub.io that OLMv0 uses.

[joelanford]

I actually don't think the curl <releaseScript> | bash is all that bad of an installation process. The fact that that's the only place we have it documented isn't ideal though. I'd almost split this into 3 different things to do, in order:

1. Add a ClusterCatalog for quay.io/operatorhubio/catalog:latest to our existing install script.
2. Improve our docs (and also docs process/developer awareness) to have a more user-centric (rather than developer-centric) place to find installation instructions.
3. (maybe) Build tooling into a common tool (maybe kubectl-operator?) that can automate installation/upgrade of OLMv1.

[trgeiger]

/assign

[trgeiger]

Item number 1 from Joe's message is addressed by MR 1079. Not sure if we should break items 2 and 3 out into separate issues and close this one or if we should track those here.

[DrummyFloyd]

hi , from what i understand here, you're talking about how OLMV1 will be installed ? because OLMV1, fill the gitops gap from the V0 , you shoudl definitely , add an Helm release of the Operator could be use with some tools like FLuxCD or Argocd

[djmcgreal]

Is running curl and bash from terraform the best option? If so, it’s far from ideal.

[github-actions[bot]]

Issues go stale after 90 days of inactivity. If there is no further activity, the issue will be closed in another 30 days.

[github-actions[bot]]

This issue has been closed due to inactivity.