Kustomize vars not applied to Namespace resources

[anth0d]

You can run this to reproduce the issue. (Thanks to @tkellen for the idea on how to share repro steps easily)

Expected: $(MY_NAMESPACE) is actually substituted.

#!/usr/bin/env bash

cd "$(mktemp -d)"

cat <<EOF > kustomization.yml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
vars:
- name: MY_NAMESPACE
  objref:
    kind: ServiceAccount
    name: my-service-account
    apiVersion: v1
  fieldref:
    fieldpath: metadata.namespace
resources:
- namespace.yaml
- other.yaml
EOF

cat <<EOF > namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: \$(MY_NAMESPACE)
EOF

cat <<EOF > other.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: some-namespace
EOF

tree
kustomize build .

Output:

2019/10/30 17:36:42 well-defined vars that were never replaced: MY_NAMESPACE
apiVersion: v1
kind: Namespace
metadata:
  name: $(MY_NAMESPACE)
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: some-namespace

[jbrette]

Looks to be working ok. here.

[anth0d]

That example doesn't work for me as written. There are lines in "Preparation Step Other0" (kustomization.yml) which are commented out. Also the fully-qualified reference $(ServiceAccount.my-service-account.metadata.namespace) does not work at all for me.

If I add an additional configuration (configurations:) pointing to an additional file containing a varReference, and reference the var name MY_NAMESPACE it works -- but there is no documentation explaining why that would be necessary. I would love to understand the design decision that leads to this behavior because as a user it feels a little confusing why I need multiple configs defined in separate files.

[jbrette]

Added comment check here. Referencing one object into another is really error prone in Kustomize.
Over the last week alone, #1734 and #1721 had the same cause.

If I grep for varReference in the list of issues, so similar to your issue:
#680
#952
#964
#976
#1190
#1250
#1251
#1268
#1295
#1295
#1367
#1390
#1540
#1553
#1592
#1710
#1713
#1721
#1733
#1734

[fejta-bot]

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]

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]

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

[k8s-ci-robot]

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