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

Helm compiler does not enforce namespace #801

Closed
lingwooc opened this issue Dec 1, 2021 · 1 comment
Closed

Helm compiler does not enforce namespace #801

lingwooc opened this issue Dec 1, 2021 · 1 comment

Comments

@lingwooc
Copy link

lingwooc commented Dec 1, 2021

Describe the bug/feature
The helm compiler uses helm template which allows you to pass through a namespace as a parameter. Unfortunately due to architectural mistakes in helm helm template -n namespace | kubectl apply and helm install -n namespace are not equivalent. helm template does not enforce a namespace, only populates templated namespaces. They don't seem much interesting in fixing it either helm/helm#3553. This causes problems in charts which do not explicitly set namespaces (such as tesoro). Other tools which use helm template internally (argocd for instance) manually enforce a namespace.

To Reproduce
Steps to reproduce the behavior:

  1. Render the tesoro helm chart with kapitan
  2. Check the resource namespaces (spoiler altert: they aren't there)

Expected behavior
Namespaces are set in yaml files.

** If it's a bug (please complete the following information):**

  • 0.30.0-rc.0

Additional context
I am intending to fix this with a secondary external compiler step but it would be nice if kapitan either had an additional parameter to enforce namespace or used the helm_params.namespace value to automatically enforce it.

@ademariag
Copy link
Contributor

Hello Chris,

Thank you for opening this issue. First of all, please join our #kapitan channel on the kubernetes slack so we can get to chat more about this topic.

I see what you mean, but using the helm input we think it would be wrong to force a behaviour that would not be similar to what helm does on the first place.

What I see possible in the future is to allow for something like a generator to alter the helm chart in a more explicit way, together with making any other changes that are not supported by the helm chart itself.

@ademariag ademariag closed this as not planned Won't fix, can't repro, duplicate, stale Mar 9, 2023
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