kustomize
kustomize copied to clipboard
kubernetes-sigs
Line breaks on long strings with spaces
When combining helm templates with kustomize overlays, a line break is inserted when the line is very long and contains spaces.
Tested versions: 2.0.1 and 2.0.3 Using test/base.yml:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: test
labels:
app.version: "{{ .Values.services.mariadb.app.version }}"
spec:
template:
spec:
containers:
- name: mariadb
image: "thisIsAReallyLongRepositoryLinkThatResultsInALineBreakWhenBuildingWithKustomize/mariadb:{{ .Values.services.mariadb.image.version }}"
and test/kustomization.yml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- base.yml
results in
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app.version: '{{ .Values.services.mariadb.app.version }}'
name: test
spec:
template:
spec:
containers:
- image: thisIsAReallyLongRepositoryLinkThatResultsInALineBreakWhenBuildingWithKustomize/mariadb:{{
.Values.services.mariadb.image.version }}
name: mariadb
Expected Behavior:
- Line without line break
- Also, the string/quoted value of the image name in base.yml is converted to an unqouted value on build while the
app.versionlabel is enclosed in single quotes. I would expect that either the quotes are not removed at all or the quoting behavior is constant
I think if https://github.com/go-yaml/yaml/pull/455 gets merged that might be the signal to migrate to yaml.v3, and unlimited line lengths...
This behavior is still in v3.0.1. Using the same input files, the output has line breaks:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app.version: '{{ .Values.services.mariadb.app.version }}'
name: test
spec:
template:
spec:
containers:
- image: thisIsAReallyLongRepositoryLinkThatResultsInALineBreakWhenBuildingWithKustomize/mariadb:{{
.Values.services.mariadb.image.version }}
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Have the same issue here. Need to keep the formatting as is without breaking long lines. Any ideas?
@kristofferahl, we worked around this by using:
attribute: |
very long line
Not sure if this is semantically 100% equal, though. It mitigated the issue in our specific case.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@laverya: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
There's a fix in gopkg.in/yaml.v2, now released as v2.3.0 - I'll make a PR to update kustomize to this version. (basically, if the string doesn't have newline literals in it, v2.3.0 won't split the string over multiple lines when encoding things - previously it would wrap before 80 characters)
Just validated, and 3.6.1 still exhibits this behavior:
kustomization.yaml
resources:
- deployment.yaml
deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 1
selector:
matchLabels:
component: test
template:
metadata:
labels:
component: test
spec:
containers:
- name: test
image: "test"
env:
- name: DATABASE_URL
value: postgres://{{repl ConfigOption "database_user"}}:{{repl ConfigOption "database_password"}}@db.{{repl Namespace}}.svc.cluster.local:5432/db
yields this:
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
spec:
replicas: 1
selector:
matchLabels:
component: test
template:
metadata:
labels:
component: test
spec:
containers:
- env:
- name: DATABASE_URL
value: postgres://{{repl ConfigOption "database_user"}}:{{repl ConfigOption
"database_password"}}@db.{{repl Namespace}}.svc.cluster.local:5432/db
image: test
name: test
$ kustomize version
{Version:3.6.1 GitCommit:c97fa946d576eb6ed559f17f2ac43b3b5a8d5dbd BuildDate:2020-05-28T01:07:36+01:00 GoOs:darwin GoArch:amd64}
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
We should get a unit test in place that displays this behavior (or confirms that it's gone).
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
@fejta-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten.Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
This is still an issue, with latest version of kustomize bundled with Argo CD 2.0.1. I use the kustomized-helm pattern, but kustomize corrupts the following
BEFORE
containers:
- name: createdb-{{ $index }}
image: postgres:11-alpine # A relatively small official image that can run psql
command:
- sh
- -c
- >
while ! pg_isready -U postgres -h {{ template "timescaledb.fullname" $ }}; do sleep 1; done;
echo "${SQLCOMMAND}" | psql --file=- --echo-queries -d "${ACCESS_SVC_CONNSTR}" \
--set ON_ERROR_STOP=1 \
--set dbname="${DBNAME}"
AFTER
containers:
- name: createdb-{{ $index }}
image: postgres:11-alpine # A relatively small official image that can run psql
command:
- sh
- -c
- >
while ! pg_isready -U postgres -h {{ template "timescaledb.fullname" $ }}; do sleep 1; done;
echo "${SQLCOMMAND}" | psql --file=- --echo-queries -d
"${ACCESS_SVC_CONNSTR}" \
--set ON_ERROR_STOP=1 \
--set dbname="${DBNAME}"
Still have this problem, even with kustomize v4.3.0. In my case it's when you have a patch file with a really long string as the replacement value.
I see a note all the way back in https://github.com/kubernetes-sigs/kustomize/releases/tag/api%2Fv0.8.11 that forced line wrapping is supposed to no longer be present. Doesn't seem to be the case though, at least on 4.3.0 which we are currently using.
I can't find an issue/PR that explicitly states that this has been dealt with. Has it fallen through the cracks?
@cprivite: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
I am still experiencing this with Kustomize version v4.5.2.
Please reopen this issue.
@KnVerey @natasha41575 @yuwenma Sorry to ping you all, but we need some eyes on this from active owners/reviewers. Can you please re-open this issue? This is causing real problems today.
Example new user story would be building a yaml with an upstream open source project's yaml (like calico) as one of your bases that you don't have control over, but has really long lines (their description fields). You cannot use any version of kustomize after 4.0.4 if you want to use those upstream source files without modification.
We can reopen this issue for tracking, but there's nothing really that we (kustomize) can do about it because it's a bug in the underlying go-yaml library.
@maxhomann: This issue is currently awaiting triage.
SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
We can reopen this issue for tracking, but there's nothing really that we (kustomize) can do about it because it's a bug in the underlying go-yaml library.
That's fine, but none of us (the people having the issue) know what that bug is or how to fix it or who to bug to get it fixed. It sounds like you do, so could you or someone you appoint champion this cause for us with the go-yaml community?