Open in-cloud-opensource opened 2 years ago
This just bit me too. I know "+1" comments are frowned upon, but I think this is a serious enough bug to give this page a bump.
Same happening.
{Version:kustomize/v4.5.5 GitCommit:daa3e5e2c2d3a4b8c94021a7384bfb06734bcd26 BuildDate:2022-05-20T20:21:22Z GoOs:darwin GoArch:amd64}
Helm chart redis from Bitnami.
How to bypass it with kustomize? Basically the replicas fail as they try to connect to master in default namespace instead.
- name: REDIS_MASTER_HOST
value: {{ template "common.names.fullname" . }}-master-0.{{ template "common.names.fullname" . }}-headless.{{ .Release.Namespace }}.svc.{{ .Values.clusterDomain }}
Cheers
This bug causes kustomize to create an invalid certificate for a webhook in the bonzaicloud kafka operator. It broke a LOT of stuff. A LOT. And because of its location inside of a cert in a secret it was not easy to debug to this so please help the next user out and fix this soon. https://github.com/banzaicloud/koperator/blob/v0.21.2/charts/kafka-operator/templates/operator-deployment-with-webhook.yaml#L7
And now I'm seeing that this isn't a recent issue, from https://github.com/kubernetes-sigs/kustomize/issues/3815 it has been broken for over a year. If this cannot be made to work, at least remove the documentation for the releaseNamespace and extraArgs fields here https://kubectl.docs.kubernetes.io/references/kustomize/builtins/#_helmchartinflationgenerator_
To the future reader, the only mechanism that functions is to use the generator file usage, which is woefully under-documented anyway, then use the file as constituted here in this test https://github.com/kubernetes-sigs/kustomize/blob/1c5393216672c87d5bd553ba255d8dd3044bbf0c/plugin/builtin/helmchartinflationgenerator/HelmChartInflationGenerator_test.go#L24-L31
Create that as a separate file (say helmchart.yaml
) in the same path as your kustomize.yaml
, then in your kustomize add
generators:
- helmchart.yaml
Yes. Documentation on K8s is especially hard to follow. I removed this generator in favor of helmCharts:
that i find it somewhere in an issue like this.. and also did not find too much docs..
I also suspect (but cannot prove, because I don't have a local testing mechanism) that they could fix at least the documented releaseNamespace issue by simply adding one line here https://github.com/kubernetes-sigs/kustomize/blob/1c5393216672c87d5bd553ba255d8dd3044bbf0c/api/types/helmchartargs.go#L120
c.Namespace = old.ReleaseNamespace
extraArgs
could not be fixed as easily because it isn't supported in the new form but the namespace is, it is just silently ignored currently
The fix suggested sounds plausible and we would appreciate a PR with that + test proving it works.
/triage accepted /good-first-issue
@KnVerey: This request has been marked as suitable for new contributors.
Please ensure that the issue body includes answers to the following questions:
For more details on the requirements of such an issue, please see here and ensure that they are met.
If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue
command.
/assign
Is this still getting worked on?
I think the issue is still there
It looks like this is still being worked on here
However, @brahama pointed out that helmCharts
is the better way to go to. The docs are not up to date on this. However, there is some Chart example. In addition, you might want to look into https://github.com/kubernetes-sigs/kustomize/blob/cf3a452ddd6f83945d39d582243b8592ec627ae3/api/types/helmchartargs.go#L33 for more details on the parameters.
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the PR is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
To the future reader, the only mechanism that functions is to use the generator file usage, which is woefully under-documented anyway, then use the file as constituted here in this test
Create that as a separate file (say
helmchart.yaml
) in the same path as yourkustomize.yaml
, then in your kustomize addgenerators: - helmchart.yaml
this does not seem to work for me - can someone confirm that it works for someone else?
I would like to work on this
/assign
The above methods wouldn't work for me. For example, the fluxcd community helm chart templates is missing the namespaces fields and I couldn't get it populated by either helmchart or HelmChartInflationGenerator. However for some of the other helm charts containing templates with a templated namespace field (such as Cilium using {{ .Release.Namespace }}), I was able to alter the destination namespace.
./kustomization.yaml
resources:
- ./flux
./flux/kustomization.yaml
namespace: flux
resources:
- ./namespace.yaml
helmCharts:
- name: flux2
namespace: flux
valuesFile: ./values.yaml
releaseName: flux
version: 2.9.2
repo: https://fluxcd-community.github.io/helm-charts
IncludeCRDs: true
/remove-lifecycle stale
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
Given the number of comments on the more recent #5566 I believe this is still very much an issue.
Describe the bug
According to the documentation of the helm inflator it shall be possible to set the release namespace of the helm template. When running
kustomize build --enable-helm .
with the kustomization.ymal below the releaseNamespace is ignored.Files that can reproduce the issue
Example:
kustomization.yaml
Expected output
Expected output e.g. for ConfigMap, namesapce set to XXXXXX
Actual output
Kustomize version
{Version:kustomize/v4.5.3 GitCommit:de6b9784912a5c1df309e6ae9152b962be4eba47 BuildDate:2022-03-24T20:51:20Z GoOs:linux GoArch:amd64}
Platform Linux
Additional context
It seems that the ReleaseNamespace arguments are missing in the mapping between
HelmChartArgs
andHelmChart
see