Kustomize: nameref does not work with nested bases

Created on 28 Dec 2018  路  19Comments  路  Source: kubernetes-sigs/kustomize 
cat <<'EOF' > example/kustomization.yaml
bases:
- base

secretGenerator:
- commands:
    HELLO: printf 'world'
EOF

cat <<'EOF' > example/base/kustomization.yaml
bases:
- otherbase
EOF



md5-af9094314996ad8efa9745603fe8c056



cat <<'EOF' > example/base/otherbase/kustomization.yaml
resources:
- deployment.yaml
EOF



md5-af9094314996ad8efa9745603fe8c056



cat <<'EOF' > example/base/otherbase/deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - name: example
        image: example
        envFrom:
        - secretRef:
            name: example
EOF



md5-3cc4e44de5c62416bac3e9df2790b05d



apiVersion: v1
data:
  HELLO: d29ybGQ=
kind: Secret
metadata:
  name: example-c89hbk9m56
type: Opaque
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: example
        image: example
        name: example



md5-9eb28b15276bb6f656140f3c4564417e



apiVersion: v1
data:
  HELLO: d29ybGQ=
kind: Secret
metadata:
  name: example-c89hbk9m56
type: Opaque
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: example-c89hbk9m56
        image: example
        name: example
lifecyclrotten
Source
picture sethpollack
👍4

Most helpful comment

@Liujingfang1 Ok you are correct. The issue is not the nested bases, it breaks when you add a namePrefix.

cat <<'EOF' > kustomization.yaml
apiVersion: v1beta1
kind: Kustomization

bases:
- base

secretGenerator:
- commands:
    HELLO: printf 'world'
  name: example
EOF

cat <<'EOF' > base/kustomization.yaml
apiVersion: v1beta1
kind: Kustomization

namePrefix: foo-

resources:
- deployment.yaml
EOF

cat <<'EOF' > base/deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - name: example
        image: example
        envFrom:
        - secretRef:
            name: example
EOF
picture sethpollack on 13 Jan 2019
👍5

All 19 comments

The reference to the secret appears in a base that does not define the secret. If you create the secret in example/base/otherbase/kustomization.yaml and merge it (search for "behavior: merge") in example/kustomization.yaml I believe your code will work.

jcassee picture jcassee on 30 Dec 2018
👎1 👍1

@sethpollack It should work. Can you try version 1.0.11?

Liujingfang1 picture Liujingfang1 on 8 Jan 2019

@Liujingfang1 Ok you are correct. The issue is not the nested bases, it breaks when you add a namePrefix.

cat <<'EOF' > kustomization.yaml
apiVersion: v1beta1
kind: Kustomization

bases:
- base

secretGenerator:
- commands:
    HELLO: printf 'world'
  name: example
EOF

cat <<'EOF' > base/kustomization.yaml
apiVersion: v1beta1
kind: Kustomization

namePrefix: foo-

resources:
- deployment.yaml
EOF

cat <<'EOF' > base/deployment.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: example
spec:
  template:
    spec:
      containers:
      - name: example
        image: example
        envFrom:
        - secretRef:
            name: example
EOF
sethpollack picture sethpollack on 13 Jan 2019
👍5

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

fejta-bot picture fejta-bot on 28 Apr 2019

/remove-lifecycle stale

george-angel picture george-angel on 29 Apr 2019

@sethpollack, @jcassee is right - adding a generator to the base, using the same name and merging from higher-level layers works, even if namePrefix is provided.

R=$(mktemp -d /tmp/kustomizetest.XXXXXXX)
mkdir -p $R/base/

cat <<HERE > $R/base/deploy.yaml
kind: Deployment
metadata:
  name: foobar
spec:
  template:
    spec:
      containers:
      - name: foobar
        image: busybox
        envFrom:
        - secretRef:
            name: xxx
        - configMapRef:
            name: yyy
HERE

cat <<HERE > $R/base/kustomization.yaml
resources:
- ./deploy.yaml
namePrefix: lalala-

secretGenerator:
- name: xxx
  literals:
  - password=123456
HERE

cat <<HERE > $R/kustomization.yaml
resources:
- ./base

secretGenerator:
- name: xxx
  behavior: merge
  literals:
  - password=12345699999

configmapGenerator:
- name: yyy
  literals:
  - password=123456
HERE

kustomize build $R
valer-cara picture valer-cara on 22 Jul 2019

@sethpollack @Liujingfang1 PR 1378 is solving the issue

Reproduce the environment here

When issuing 3.0.3

$HOME/bin/kustomize.3.0.3 build .

apiVersion: v1
data:
  HELLO: d29ybGQ=
kind: Secret
metadata:
  name: example-5cm72hhtk8
type: Opaque
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: foo-example
spec:
  template:
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: example
        image: example
        name: example

When using 3.0.3 + PR1378

$HOME/bin/kustomize.PR1378 build .

apiVersion: v1
data:
  HELLO: d29ybGQ=
kind: Secret
metadata:
  name: example-5cm72hhtk8
type: Opaque
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: foo-example
spec:
  template:
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: example-5cm72hhtk8
        image: example
        name: example
jbrette picture jbrette on 22 Jul 2019

@valer-cara I think that PR. If we use your example, without the PR the configMapRef is wrong and does not contain the hash. With the PR the configMapRef is correct.

$HOME/bin/kustomize.3.0.3 build .

apiVersion: v1
data:
  password: "123456"
kind: ConfigMap
metadata:
  name: yyy-bkfmbb8t66
---
apiVersion: v1
data:
  password: MTIzNDU2OTk5OTk=
kind: Secret
metadata:
  annotations: {}
  labels: {}
  name: lalala-xxx-ctd2ckb7h7
type: Opaque
---
kind: Deployment
metadata:
  name: lalala-foobar
spec:
  template:
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: lalala-xxx-ctd2ckb7h7
        - configMapRef:
            name: yyy
        image: busybox
        name: foobar

$HOME/bin/kustomize.PR1378 build .

apiVersion: v1
data:
  password: "123456"
kind: ConfigMap
metadata:
  name: yyy-bkfmbb8t66
---
apiVersion: v1
data:
  password: MTIzNDU2OTk5OTk=
kind: Secret
metadata:
  annotations: {}
  labels: {}
  name: lalala-xxx-ctd2ckb7h7
type: Opaque
---
kind: Deployment
metadata:
  name: lalala-foobar
spec:
  template:
    spec:
      containers:
      - envFrom:
        - secretRef:
            name: lalala-xxx-ctd2ckb7h7
        - configMapRef:
            name: yyy-bkfmbb8t66
        image: busybox
        name: foobar
jbrette picture jbrette on 22 Jul 2019
❤1

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

fejta-bot picture fejta-bot on 20 Oct 2019

/remove-lifecycle stale

george-angel picture george-angel on 20 Oct 2019

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

fejta-bot picture fejta-bot on 18 Jan 2020

/remove-lifecycle stale

george-angel picture george-angel on 19 Jan 2020

Got bitten by this, anyone got a workaround?

imranismail picture imranismail on 22 Jan 2020

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

fejta-bot picture fejta-bot on 21 Apr 2020

/remove-lifecycle stale

george-angel picture george-angel on 22 Apr 2020

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

fejta-bot picture fejta-bot on 21 Jul 2020

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

fejta-bot picture fejta-bot on 20 Aug 2020

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 picture fejta-bot on 19 Sep 2020

@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.

k8s-ci-robot picture k8s-ci-robot on 19 Sep 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

sidps picture sidps  路  5Comments
davidknezic picture davidknezic  路  3Comments
pst picture pst  路  4Comments
karlmutch picture karlmutch  路  5Comments
bugbuilder picture bugbuilder  路  3Comments