Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

as long as there is a manual Subscription, other automatic operators cannot be automatically installed or upgraded #3152

Open
zhhray opened this issue Jan 11, 2024 · 1 comment
Labels
kind/bug Categorizes issue or PR as related to a bug.

Comments

@zhhray
Copy link

zhhray commented Jan 11, 2024

Bug Report

What did you do?

  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?

What did you expect to see?
I expect that the automatic Subscription is automatically approved and the manual Subscription is manually approved at any time, without influencing each other.

What did you see instead? Under which circumstances?
As long as the operator is deployed in the same namespace, the preceding problems must exist.

Environment

  • operator-lifecycle-manager version: v0.26.0
  • Kubernetes version information: v1.27
@zhhray zhhray added the kind/bug Categorizes issue or PR as related to a bug. label Jan 11, 2024
@zhhray
Copy link
Author

zhhray commented Jan 29, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug.
Projects
None yet
Development

No branches or pull requests

1 participant