kustomize-controller: substituteFrom value used in a yaml template are not being rendered correctly when used with quotes.
I believe this the correct project for this bug report, but if it’s not I’m more than happy to resubmit it somewhere else.
I have a Kustomization (kustomize.toolkit.fluxcd.io/v1beta2) which pulls values from a configMap using postBuild: substituteFrom: The values are then used in a HelmRelease (helm.toolkit.fluxcd.io/v2beta1) called by this Kustomization. One of the values is an AWS account number which is defined as a string in the configMap. The variable is then used in the HelmRelese manifest and wrapped in quotes. Once the Kustomize controller renders this template and applies it to Kubernetes, the double quotes get stripped away.
Example:
Snippet of my Kustomization file:
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
...
spec:
postBuild:
substituteFrom:
- kind: ConfigMap
name: myvalues
Configmap that’s being called above:
apiVersion: v1
kind: ConfigMap
metadata:
name: myvalues
data:
AWS_ACCOUNT_ID: "887265102384" # Not our ACTUAL account number. :)
...
Snippet of my Helmrelease yaml file thats called as part of the above Kustomization
---
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: myhelmrelease
...
spec:
values:
customMetadata: # Experiment with adding quotes multiple ways.
- name: aws_account_id1
value: '887265102384' # Passing in a static value with quotes as a control
- name: aws_account_id2
value: "${AWS_ACCOUNT_ID}" # Value wrapped in double quotes
- name: aws_account_id3
value: '${AWS_ACCOUNT_ID}' # Value wrapped in single quotes
- name: aws_account_id4
value: "'${AWS_ACCOUNT_ID}'" # Value wrapped in double then single quotes
- name: aws_account_id5
value: '"${AWS_ACCOUNT_ID}"' # Value wrapped in single then double quotes
- name: aws_account_id6
value: ${AWS_ACCOUNT_ID} # Value without any quotes
Snipped of Helmrelease manifest with values that ends up in my cluster:
$ kubectl get helmrelease myhelmrelease -o yaml
...
customMetadata:
- name: aws_account_id1
value: "887265102384"
- name: aws_account_id2
value: 887265102384
- name: aws_account_id3
value: 887265102384
- name: aws_account_id4
value: '''887265102384'''
- name: aws_account_id5
value: '"887265102384"'
- name: aws_account_id6
value: 887265102384
...
What I’m expecting is the account number value to be rendered with quotes when using the variable name surrounded by quotes. ie ‘${AWS_ACCOUNT_ID}’ should render to “887265102384”.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 11
- Comments: 16 (5 by maintainers)
Commits related to this issue
- fix: adds workaround for fluxcd bug - https://github.com/fluxcd/kustomize-controller/issues/554 — committed to pauwels-labs/flux-infra by deleted user 2 years ago
- fix: tries second work-around for quotes issue - https://github.com/fluxcd/kustomize-controller/issues/554 — committed to pauwels-labs/flux-infra by deleted user 2 years ago
This is not especially helpful for Flux, but there is a system-based (eg. non-workaround) solution in the Weaveworks product (enterprise software warning):
https://docs.gitops.weave.works/docs/gitops-templates/templates/#rendering-templates
Bringing this up because it might be something we can still aim to add to Kustomize Controller.
Then it can be solved generally without suggesting that you need to buy an enterprise product – in the solved version, you could swap out your render type for
templatingfrom the defaultenvsubstmode, and even set your own delimiters in case the default ones are not helping in some particularly rough YAML.I got really very excited when I found this, since I’ve seen many Flux users struggle with this issue, and I don’t have any workaround to offer which I think is reliable anymore, but there’s this. The envsubst templating is not terribly well equipped to handle this issue, because of the time that it’s applied (which is, (I think?) after the YAML has already been parsed once, so quotes get removed.)
I wouldn’t suggest this could be implemented quickly in Flux because I’m not in a position to volunteer to do it, nor have I checked the design to understand if it could be cleanly implemented directly in Flux without major compromises. But as I have worked with the enterprise Weave GitOps product, and explored the template engine, pipelines, and related capabilities, I found this solution quite handy and definitely thought it needed to get a mention here.
is there any progress on finding/agreeing on a permanent fix for this issue? Or could we introduce a more “standard” templating alternative (e.g. go template)?
Current workaround is to define variable as:
pulsarGcWaitTime: "'50000'"and then in manifest:PULSAR_PREFIX_gcWaitTime: "${pulsarGcWaitTime:='60000'}"it will be rendered as:PULSAR_PREFIX_gcWaitTime: "50000"would be nice to have a better solution to be able to propagate typed variable (string in this case)
@vliska I didn’t test it but have you tried triple quoting the values, e.g. like
key: '"\"value\""'? This might keep the quotes for another substitution.We have the same issue, but with booleans. Basically any boolean-like value is converted to boolean and breaks schema validation for most objects. Workarounds don’t work for us, as sometimes we use value inside strings (so quotes are put there too), and even for simple strings they still convert values to bool