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

[enhancement] operators all have their own namespaces #158

Open
eformat opened this issue Dec 15, 2022 · 3 comments
Open

[enhancement] operators all have their own namespaces #158

eformat opened this issue Dec 15, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@eformat
Copy link
Member

eformat commented Dec 15, 2022

If possible, lets see if we can deploy all operators to their own namespaces.

That way, if a breaking change happens in an operator (as it did with gitops operator 1.7.0) we could pin it to a Manual installed version very easily.

With many operators sharing the openshift-operator namespace, becomes a lot harder to do this as every operator in the namespace would need to be Manual if one is (linked to the OG/OLM)

The dependency here will be if individual operators support this capability (many do).

@eformat eformat added the enhancement New feature or request label Dec 15, 2022
@jfilipcz
Copy link
Contributor

Here's the first step - removing hardcoded NS on GitOps operator chart: redhat-cop/helm-charts#316

@jfilipcz
Copy link
Contributor

One operator from the set currently used does not support InstallModeType OwnNamespace - OpenShift Pipelines. That's not a big deal as it resides in its own namespace. General idea seems to be technically feasible.

@jfilipcz
Copy link
Contributor

On the other hand - what if we flip the behavior a bit. Instead of using latest version of everything on the target environment, we can ensure (CI&CD) that whatever "latest" release we produce, it has the latest components - but components at a fixed version. This way we'll ensure the things are reasonably fresh while not risking unexpected updates during the course itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants