Subscription emits InstallPlan containing update to unrelated operator/clusterServiceVersion

[dacleyra]

Bug Report

What did you do?

Purpose: Curate an install of specific ClusterService versions by using Subscription with startingCSV and Manual approval for InstallPlan. This is an attempt to avoid #1076

Create a Subscription requiring manual approval to install a clusterServiceVersion that is not at the latest level, startingCSV: openshift-pipelines-operator.v0.5.2
Create a second subscription requiring manual approval to install another operator, startingCSV: serverless-operator.v1.0.0

What did you expect to see?
Expected to have openshift-pipelines-operator.v0.5.2 and serverless-operator.v1.0.0 versions installed

What did you see instead? Under which circumstances?
openshift-pipelines-operator.v0.7.0 was installed.
The automatically emitted InstallPlan for serverless-operator contained an update for openshift-pipelines-operator.

    clusterServiceVersionNames:
    - openshift-pipelines-operator.v0.7.0
    - serverless-operator.v1.0.0

The CSV for serverless-operator does not contain a required for openshift-pipelines-operator.

Environment

• operator-lifecycle-manager version: 0.11.0 & 0.12.0

OLM 0.11.0 with OCP 4.2-RC3 was attempted

OLM 0.12.0 with OCP 4.2.-RC3 was attempted via disabling CVO
oc scale --replicas 0 -n openshift-cluster-version deployments/cluster-version-operator
apply
https://github.com/operator-framework/operator-lifecycle-manager/tree/master/deploy/ocp/manifests/0.12.0

• Kubernetes version information:

Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+$Format:%h$", GitCommit:"$Format:%H$", GitTreeState:"", BuildDate:"1970-01-01T00:00:00Z", GoVersion:"go1.12.8", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.6+c795c6c", GitCommit:"c795c6c", GitTreeState:"clean", BuildDate:"2019-10-07T15:17:54Z", GoVersion:"go1.12.8", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind: OCP 4.2-rc3

Possible Solution

Additional context

The problematic automatically emitted InstallPlan has multiple metadata.ownerReferences, referencing both Subscriptions.

Attached Subscriptions, InstallPlans, ClusterServiceVersions

sic.yaml.txt

[ecordell]

Hi @dacleyra

The good news is that #1076 is now resolved, which may be a more immediate fix to your problems. It will be backported to 4.2 shortly.

This is expected behavior given the actions performed. Allow me to annotate what happened:

1. Create a Subscription for pipeline operator starting at openshift-pipelines-operator.v0.5.2
   • OLM created an installplan for openshift-pipelines-operator.v0.5.2 - I see this in your attatchment.
   • The installplan was manually approved, so the CSV for 0.5.2 was installed.
2. Create a Subscription for serverless starting at serverless-operator.v1.0.0
   • OLM must reconcile the update settings you have specified, which are:
     • Manual approval
     • Subscribe to updates for serverless-operator starting at serverless-operator.v1.0.0
     • Check for updates for openshift-pipelines-operator starting at 0.5.2
   • OLM sees that 0.5.2 of openshift-pipelines-operator is installed, so it checks for updates and finds 0.7.0
   • OLM sees that no serverless-operator is installed, so it uses the startingCSV of v1.0.0
   • OLM creates an unapproved installplan for 0.7.0 and 1.0.0

It seems like the confusion is around startingCSV - this indicates where OLM should begin walking through operator updates, it does not freeze the operator at the particular version.

Subscriptions indicate a desire for updates. If updates aren't desired, you can remove the Subscription after install.

As an additional reference, I would point you to our docs on dependency resolution.

If you're interested, we have a v2 set of APIs we are working on that will help address your use-case much better. Specifically the proposed Install api will allow you to ask for an exact set of operators to install (without updates).

[dacleyra]

Thanks, I will look at the v2 API

What I consider a problem is that during these steps

OLM sees that 0.5.2 of openshift-pipelines-operator is installed, so it checks for updates and finds 0.7.0
OLM creates an unapproved installplan for 0.7.0 and 1.0.0

The Subscription & associated InstallPlan for serverless-operator.v1.0.0 (install-7t46x) contains the CSV update for openshift-pipelines-operator.v0.7.0

The reconcile generated an individual InstallPlan for the openshift-pipelines-operator.v0.7.0 update (install-v2lfk)

I don't think that update to openshift-pipelines-operator.v0.7.0 has any business being in InstallPlan install-7t46x

I would expect with startingCSV and a Subscription with Manual installPlanApproval would allow one to start at a CSV and only approve related upgrades / InstallPlans manually as desired.

[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.

[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.

[ecordell]

I would point you to this enhancement: https://github.com/openshift/enhancements/blob/master/enhancements/olm/simplify-apis.md

We discuss some of these UX issues more in depth there.

I don't think that update to openshift-pipelines-operator.v0.7.0 has any business being in InstallPlan install-7t46x

They're currently resolved as a set, because a future version of one operator may introduce a dependency on another. It's simpler to raise them for approval as a group. But the linked enhancement discusses emitting different Install resources for disconnected sets of operators.