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

Install the operator in another namespace than the default one #52

Open
dmartin35 opened this issue Jun 2, 2020 · 3 comments
Open

Install the operator in another namespace than the default one #52

dmartin35 opened this issue Jun 2, 2020 · 3 comments

Comments

@dmartin35
Copy link
Contributor

For some security reasons, some users are given a single namespace to play with , and cannot create another namespace.

The current kustomization prevents from installing the operator in other namespace than the default chaostoolkit-crd namespace.

To change the installation namespace, two steps are required:

  • changes the namespace in kustomization.yaml files (depending on the overlay)
  • changes the default command for the container in the deployment, to listen to another namespace (otherwise the operator will not work and remain silent)
@dmartin35
Copy link
Contributor Author

  • Is this something we want to be customizable at install ?
  • do we want to at least for the users to have the default chaostoolkit-crd namespace ?
  • do we only document how to change the namespace in the kustomizations and deployment ? maybe other places in the manifest ?

@dmartin35
Copy link
Contributor Author

I created a branch for that use case, that can be used as example
https://github.com/chaostoolkit-incubator/kubernetes-crd/tree/install-in-another-namespace

@Lawouach
Copy link
Contributor

Lawouach commented Jun 3, 2020

This is tricky. kustomize doesn't support on the fly parameters from its CLI. So, either we document how to simply edit these files indeed (is it an "advanced" case afterall?) or we consider that kustomize is not the right solution and look elsewhere (helm for instance).

Helm would bring us a little more exposure but that's a different discusion. So, I'm in favour of keeping kustomization files the main approach as slong as we can edit in a single place only perhaps? to keep things easy.

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

No branches or pull requests

2 participants