Var reference does not work in volumes

[phillebaba]

Var reference does not work when used in volumes.

kind: Deployment
apiVersion: apps/v1
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: fuseim.pri/ifs
            - name: NFS_SERVER
              value: $(NFS_SERVER)
            - name: NFS_PATH
              value: /var/nfs
      volumes:
      - name: nfs-client-root
        nfs:
          server: $(NFS_SERVER)
          path: /var/nfs

When kustomizing this manifest with a varible that references a Service ClusterIP the following is outputed.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  namespace: kube-system
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client-provisioner
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      containers:
      - env:
        - name: PROVISIONER_NAME
          value: fuseim.pri/ifs
        - name: NFS_SERVER
          value: 10.43.118.159
        - name: NFS_PATH
          value: /var/nfs
        image: quay.io/external_storage/nfs-client-provisioner-arm:latest
        name: nfs-client-provisioner
        volumeMounts:
        - mountPath: /persistentvolumes
          name: nfs-client-root
      serviceAccountName: nfs-client-provisioner
      volumes:
      - name: nfs-client-root
        nfs:
          path: /var/nfs
          server: $(NFS_SERVER)

I would expect the $(NFS_SERVER) in the volume to also be replaced with the ClusterIP. I need this as there are currently issues with using the service dns to resolve the ip of a nfs server running in the same cluster.

[jbrette]

@phillebaba You can solve that the complicated way by changing the variable reference configuration.
Have a look here
and especially at the varreference.yaml kustomize config file

varReference:
- path: spec/template/spec/volumes[]/nfs
  kind: Deployment

or you can do it the easy way leveraging this PR. Check how much more simple the configuration is.
No need for varReference file nor entry in the kustomization.yaml.
The only thing you need to do is to have an variable name like this:
$(..)

In any case, I don't think there is a bug in kustomize.

/cc @monopole @Liujingfang1 @ian-howell

[phillebaba]

Yes you are right that this is not a bug. In hindsight I realize that I should have spent more time researching my issues. Your example solved my issue, and I must thank you @jbrette as they were really detailed and easy to understand.

I guess the reason I thought this was a bug was because I dont really understand why kustomize does variable replacement in some fields by default and not in others.

I will be following your PR as I do agree that it creates a much clean kustomization file.

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