Can't approve install plan for just one operator in cluster scope

[CAIOFCP]

Type of question

General Conextt

Question

What did you do?
I have installed an operator that has cluster scope. I set the install plan approval to Manual since I need to keep it in a specific csv due to some project requirements. The thing is that now if I try to install any other operator with cluster scope the framework claims to approve a install plan that contain upgrade for both, the one I have set to Manual approval and the new one I'm installing. Is that possible to approve just one instead of both ?

What did you expect to see?
I would expect to be able to approve a install plan by operator and not one per operator scope.

What did you see instead? Under which circumstances?
I've been forced to uninstall the operator I need to keep in a specific csv and install again after got the second operator installed.

Environment

• operator-lifecycle-manager version:

OCP 4.6

• Kubernetes version information:

1.19

• Kubernetes cluster kind:

Additional context
Operator Hub

[dinhxuanvu]

This is a console issue as you can certainly approve InstallPlan one by one on OLM (via manually kubectl command edit). We will close this issue out and reference to a console issue instead.

[njhale]

This is a console issue as you can certainly approve InstallPlan one by one on OLM (via manually kubectl command edit). We will close this issue out and reference to a console issue instead.

If I understand correctly, the behavior described in the original question is expected and most likely not a bug with console.

Today, upgrades for operators with Subscriptions in the same namespace are usually bound together in a single InstallPlan because upgrade resolution requires OLM to consider the entire graph of dependencies at once; i.e. upgrading any operator may introduce or drop any number of additional dependencies. Simply put, the UX of approving an operator without approving its dependency seems like it would also result in unhappy campers (as the first operator is likely to fail), although we could likely get away with shunting unrelated operators into their own InstallPlans. We would, however, welcome any thoughts you have about how to work around these UX issues.

Thinking alternatively, could we reframe this problem as "version pinning"? What if you had an API, on cluster, that allowed you to "pin" operators to specific versions so that you only resolved updates for the operators you wanted? There's an EP in review now that touches on a way to inject additional constraints into dependency resolution. I could see a world where you drop more "constraint properties" into the property ConfigMap that require specific operator versions.

[shalberd]

"Today, upgrades for operators with Subscriptions in the same namespace are usually bound together in a single InstallPlan because upgrade resolution requires OLM to consider the entire graph of dependencies at once; "

What does "usually" mean here?

This used to work in openshift 4.7, individual / separate install plans for subscriptions to operators with installPlan manual. What happened in the last 6 months so that suddenly, individual subscriptions in openshift-operators are put into one installPlan? This is totally counter-intuitive.

[chris93111]

Hello any update ? operator with cluster scope can't be updated separately