Discusses manual installation of operator in the same namespace

[Ray Zh]

Dear all:

    I will feed back an olm implementation, or functional logic.

1. In the same ns, I need to deploy multiple operators, because the spec.targetNamespace of the operatorgroup under this ns is "", I want all-namespace operators to be installed in this namespace.
2. In the same ns, when I create a Subscription, spec.installPlanApproval is set to manual, but if I create multiple other spec.installPlanApproval automatic subscriptions. None of these operators are automatically approved, and they are all affected by the manual Subscription.
3. We can see the implementation in the code: https://github.com/operator-framework/operator-lifecycle-manager/blob/master/pkg/controller/operators/catalog/operator.go#L1380
4. I want to know, why design it this way?

   But I expect that the automatic Subscription is automatically approved and the manual Subscription is manually approved at any time, without influencing each other.

   Obviously, as long as the operator is deployed in the same namespace, the preceding problems must exist.

 

[Ray Zh]

Why, I wonder, is no one talking about this？

[Kevin Rizza]

Hello,

Sorry, I missed your last message. So, to answer your question, this is actually because of a number of limitations to the way that dependency resolution worked at the time that the installplan api was implemented. Dependency resolution is a nontrivial combinatorial problem that later versions of OLM are now solving with a SAT solver that is integrated into the runtime. But, at the time the architecture was designed, no sat solver was implemented. To reduce the runtime complexity of solving for dependencies, the decision was made to aggregate install resolution of the set of operators that are installed into a namespace into a single set. That's really what the installplan is -- a definition of the set of things that need to be installed under the constraints of that installation context.

So, tldr: it would be possible today to have independent or interdependent installplans that would allow manual upgrades, but unless someone does the work of disambiguating installplans into discrete upgrades when we resolve and find that there is no dependency relationship, it can't be implemented. And given that most of the folks who are working on OLM are focused on the v1 project, it most likely won't be implemented unless another upstream contributor is interested in solving that problem.

Thanks,

Kevin

--
You received this message because you are subscribed to the Google Groups "operator-framework-olm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to operator-framework-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework-olm-dev/5af6645f-b91f-4df8-bce4-752d006a0f74n%40googlegroups.com.

[Ray Zh]

Ok, thanks for your reply. We need to consider how to avoid this case again.

[Ray Zh]

By the way, another question comes to mind: I have multiple operators that expect to manage all namespaces (i.e., operatorgroup with a targetNamespace of "").Can I separate them into different namespaces? Instead of uniformly deploying to the same ns.

在2024年2月1日星期四 UTC+8 22:31:41<kri...@redhat.com> 写道：

[Kevin Rizza]

Yep, that should work fine. Just make sure that each one of those namespaces has an operatorgroup that targets all namespaces.

> To view this discussion on the web visit https://groups.google.com/d/msgid/operator-framework-olm-dev/c084b540-68ac-4d69-b086-6a72d977b54cn%40googlegroups.com.
>