[RFE] Allow automatic installation of operator (based on startingCSV) despite Manual installPlanApproval #177

[soukron]

Not few of us are struggling with the fact that sometimes one needs an operator in a given version despite all other versions in the catalog/channel.

There are very low options there and all of them rely on automation and manual approval of install plan for such installations (that are expected to have a Manual + startingCSV pair). And everyone's reinventing the wheel using ansible, acm, k8s jobs, disconnected mirrors with only one version, etc. again and again.

I'm not sure if this has been discussed before, but it would be really great if OLM can be smart enough to cover this use case: whenever a subscription is created, if the startingCSV field is defined and there's an specific annotation, install that version automatically but let the subscription remain in Manual.

It can be a one shot comparison at creation time, no need to add extra logic for recurring modifications.

Example:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: quay-operator
  namespace: quay-enterprise
  annotations:
    olm.install-startingcsv-automatically: true
spec:
  channel: stable-3.9
  installPlanApproval: Manual
  name: quay-operator
  source: redhat-operator-index
  sourceNamespace: openshift-marketplace
  startingCSV: quay-operator.v3.9.6

[ValentinoUberti]

Hi, that would be the killer feature that many people are eagerly anticipating. I've been trying for 2 years to find the best solution (Ansible, Argo, Wave + script, etc.).

[soukron]

I made it in many different ways already also during this years.

I don't think it would be difficult to check the existence of that annotation when creating the first generation of the installplan to create it as if it was automatic without changing any other single line of code in the rest of the operator. But I'm not so versed in this operator to fully confirm it.

[kevinrizza]

This project really aims to solve this specific problem. The operator-controller's spec just has an explicit spec.versions field that will allow you to specify a specific version. It will still respect the upgrade path, but it will allow you to get a non latest version.

We are not planning on implementing anything like this in the existing operator-lifecycle-manager project, which we are considering feature complete at this point. So it will be available in the new ClusterExtension API, and not in Subscription.

[soukron]

It will still respect the upgrade path, but it will allow you to get a non latest version.

You mean: it will install automatically a version (non latest version) and will respect the Manual strategy set in the Subscription. Right?

If so, this can be closed, for sure.

[everettraven]

@soukron The new ClusterExtension API in operator-controller will allow you to set a specific version (equivalent to manual strategy in the existing Subscription API) or a version range (equivalent to automatic strategy in the existing Subscription API). OLMv1 will not know anything about the previous APIs and will not respect any configuration in existing Subscription resources.

For example, to allow for automatic upgrades within a version range the ClusterExtension might look something like:

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: clusterextension-sample
spec:
  installNamespace: default
  packageName: argocd-operator
  version: 0.6.x

This essentially says "Install the latest patch release of v0.6 of argocd-operator and automatically upgrade to new patch releases"

An example of a specific version would look like:

apiVersion: olm.operatorframework.io/v1alpha1
kind: ClusterExtension
metadata:
  name: clusterextension-sample
spec:
  installNamespace: default
  packageName: argocd-operator
  version: 0.6.0

This says "Install v0.6.0 of argocd-operator. Do not automatically upgrade". In order to upgrade to newer versions you would need to manually update the .spec.version field in the ClusterExtension to your desired version. Once modified, operator-controller will begin to install the new version.