Accessing values of the subchart with dash in the name #2192
Comments
This is a good question. I haven't had a problem doing this, but it is an inconsistency. @technosophos Should we change one of these to match the other? |
I'm currently experiencing the problem accessing values for such subchart. Next block gives me an error.
Error: UPGRADE FAILED: parse error in "gitlab/templates/deployment.yaml": template: gitlab/templates/deployment.yaml:217: bad character U+002D '-' |
Use the And we should probably change the convention. That makes it a pain to deal with things like this. I assigned the issue to myself to go change the convention. |
thanks, it works this way. |
@prydonius Do you remember the reason why we initially decided that charts should be named with dashes? I was looking through older documentation and this has been a precedent we set since the beginning. I am thinking that maybe it's not such a good idea to change it. |
? |
How would you use dash names in a control structure, such as a
|
@spearsem I think the above comment has got the right workaround for that problem. I think this should work:
Otherwise I think you can instantiate a variable that points to the annotations and use that within the range or with blocks. For example
|
@bacongobbler Does this also work for |
text/template appears to say that it should work with any structure, so I would assume yes.
|
The variable method doesn't seem to work for me. . The error just happens a line later. |
Istio port naming convention also requires dashes (see Pod Spec Requirements). |
Is there any workaround for setting vars in cli?
|
this is a real inconsistency and I have the problem too. |
I'm having this problem as well. I think it would be nice if Helm will pass values from parent chart to |
This does not work at all in templates, this example code: Client: &version.Version{SemVer:"v2.6.2", GitCommit:"be3ae4ea91b2960be98c07e8f73754e67e87963c", GitTreeState:"clean"} Same thing with both versions the same: kubectl is : |
@svidrascu , check that you have the values defined in the Chart.yaml file for that specific subchart. It looks like the templating engine can't find your variable |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Referencing the value from the .Values ended up being more complicated than I expected due to helm/helm#2192 Fixes: #92
…ricbeat.yml value This is requires because helm doesn't support accessing values with dash in the name (see helm/helm#2192 for more details).
Anyone has a solution when using toYaml ? |
any fix for U+002D '-' |
@mods/maintainers Is there an update on this? |
What kind of update? |
Hello, this issue has been opened a while ago, but the problem still occurs. The Helm Chart guidelines states that chart must be named with dashes (https://helm.sh/docs/chart_best_practices/conventions/)
Reading post above, it looks like that if I still want to use dashes this way, I need to use
In addition to that, keys in I don't think that keys naming should affect Helm templating. Is it planned to normalize that ? |
Error: bad character U+002D '-' Use --debug flag to render out invalid YAML Solution: helm/helm#2192
@bacongobbler , like whether it's going to be "fixed", i.e., that we will be able to use dashes without resorting to hacks and tricks, or whether this is a definitive "Won't fix, get used to it, fork or find something else" |
It is a limitation of the Go template language. If you would like a change, you should file it upstream in the Go project: https://github.com/golang/go If/when they fix it, we will get support for it. |
In typical Google fashion ("users are usually wrong"), this has been given a definitive "Won't fix, get used to it, fork or find something else" golang/go#23710. I think the reasons given (that specifically talk about the golang/go#23710 (comment) mentions two solutions - discouraging use of dashes (the current approach) or "rewriting the [helm] template pipelines to use the index function automatically". While I concede it might be a major undertaking, wouldn't it be possible to have a template preprocessor that could do just this? Maybe there is a hook or something that could be written to preprocess just this? While working around this is obviously possible, it just seems a little childish from the |
Bingo. I mean, it’d be great if we could make some quality of life enhancements in this area, but there are a few areas that do take a bit higher priority in our minds right now (OCI support moving to stable, for example). And to write a pre-processor is definitely a major undertaking. If you’re interested in contributing, feel free to take a look! |
For me having clarity on the situation is a great first step. We have the following:
If everyone thinks that's pretty accurate and fair, I will stop bothering everyone! :-) |
I would add that anyone who wants to look at this should consider writing a HIP - see https://github.com/helm/community/blob/master/hips/hip-0001.md Otherwise yes |
It's unclear to me what this would actually mean, do you just mean that Helm should convert dash-cased keys to camel-cased keys when it builds its values map? |
@prydonius , I really hadn't started to think about it on an implementation level. Dashes are valid as JSON keys, so are valid YAML keys, so the assumption from a user perspective is that there is no reason for them not to work as keys in I guess one approach could be to go through and convert values to camel-case, then go through the templates and do the same. But I agree the infrastructure for this is likely a lot more of a burden than it would be worth. Actually a side-bar explanation in the intro docs saying something like: Because would probably be the best situation. For me at least, what I found frustrating was a lack of clarity on exactly why it didn't work, where the issue was and who could/should fix it. The current section in the chart best practices section is a little misleading. It is not a best practice as such to not use them, it actually requires workarounds to use them. I am not sure where such an explanation, if accurate, should go though. |
+1 I agree we need to say this in the documentation somewhere, at the very least. It's definitely confusing, but I don't see a path for making this easier in Helm. Any template helper we add would act like a function in the same way |
Here is a working example of
|
With: {{ .Values.google-cas-issuer.serviceAccount.name }} I would get the error: Error: parse error at googlecasissuer.yaml:40: bad character U+002D '-' The trick is to use the "index" function from the Go templates language: {{ index .Values "google-cas-issuer" "serviceAccount" "name" }} See: helm/helm#2192 (comment) Signed-off-by: Maël Valais <mael@vls.dev>
With: {{ .Values.google-cas-issuer.serviceAccount.name }} I would get the error: Error: parse error at googlecasissuer.yaml:40: bad character U+002D '-' The trick is to use the "index" function from the Go templates language: {{ index .Values "google-cas-issuer" "serviceAccount" "name" }} See: helm/helm#2192 (comment) Signed-off-by: Maël Valais <mael@vls.dev>
With: {{ .Values.google-cas-issuer.serviceAccount.name }} I would get the error: Error: parse error at googlecasissuer.yaml:40: bad character U+002D '-' The trick is to use the "index" function from the Go templates language: {{ index .Values "google-cas-issuer" "serviceAccount" "name" }} See: helm/helm#2192 (comment) Signed-off-by: Maël Valais <mael@vls.dev>
With: {{ .Values.google-cas-issuer.serviceAccount.name }} I would get the error: Error: parse error at googlecasissuer.yaml:40: bad character U+002D '-' The trick is to use the "index" function from the Go templates language: {{ index .Values "google-cas-issuer" "serviceAccount" "name" }} See: helm/helm#2192 (comment) Signed-off-by: Maël Valais <mael@vls.dev>
With: {{ .Values.google-cas-issuer.serviceAccount.name }} I would get the error: Error: parse error at googlecasissuer.yaml:40: bad character U+002D '-' The trick is to use the "index" function from the Go templates language: {{ index .Values "google-cas-issuer" "serviceAccount" "name" }} See: helm/helm#2192 (comment) Signed-off-by: Maël Valais <mael@vls.dev> Co-authored-by: Richard Wall <richard.wall@jetstack.io>
- see helm/helm#2192 Change-Id: I3f95e1d28a7471d7bbca5104757a0f1346fcf270 Signed-off-by: Jean-Francois Weber-Marx <jf.webermarx@criteo.com>
Based on the docs, there is a convention to name charts with dashes.
But at the same time based on this doc, you should never have values with dashes.
So, let's say I have 2 dependent charts:
gitlab
andgitlab-runner
.How can I configure and access values for the subchart?
The text was updated successfully, but these errors were encountered: