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

Deprecate the "global + namespace" operator concept #2254

Closed
sebgl opened this issue Dec 12, 2019 · 1 comment · Fixed by #2530
Closed

Deprecate the "global + namespace" operator concept #2254

sebgl opened this issue Dec 12, 2019 · 1 comment · Fixed by #2530
Assignees

Comments

@sebgl
Copy link
Contributor

sebgl commented Dec 12, 2019

Relates #374.

We are moving towards not requiring the concepts of "global" and "namespace" operators anymore. The enterprise license can be applied to "any" operator that has the license role.

Without this concept, the operator can still:

  • be configured with multiple roles
  • be deployed in a particular namespace
  • manage resources in one namespace, all namespaces, N namespaces

Maintaining all-in-one + global + namespace manifests in our repository is confusing.
We should remove those manifests to only have the all-in-one version (that users can customize to their needs).
Both are used in E2E tests, that should be adapted accordingly.

It should have no particular impact on backward-compatibility, since these are just yaml manifests pre-built in a particular way. The same configuration can still be achieved by customizing the all-in-one manifest.

Also make sure READMEs, documentation and ADRs are updated accordingly.

We need to keep a toggle for the webhook as we need to turn it off in environments where multiple instances of the operator are deployed (OLM with per namespace operators)

@pebrc
Copy link
Collaborator

pebrc commented Jan 30, 2020

I just got a case of a user inadvertently configuring the licensing functionality away by running with the namespace role only. While this issue seems to mainly cover the generated manifest we should also consider removing the role flags and keep just a separate flag for the webhook. It is worth noting that this would introduce an incompatible change with regards to the operator startup parameters which we would need to call out in documentation for users using handcrafted manifests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants