Improve variable expansion to include tree structures

[ian-howell]

I would like to be able to use a variable to reference an entire tree of YAML as opposed to a single piece of primitive data. Consider the following example, where kustomize should take the entire template tree from the foo deployment and use it in the bar deployment.

.
├── bar
│   ├── deployment.yaml
│   └── kustomization.yaml
├── foo
│   ├── deployment.yaml
│   └── kustomization.yaml
├── kustomization.yaml
└── transformer.yaml

kustomization.yaml:

bases:
  - foo
  - bar
namePrefix: inlining-example-
vars:
  - name: CUSTOM_TEMPLATE
    objref:
      kind: Deployment
      name: foo
      apiVersion: apps/v1beta2
    fieldref:
      fieldpath: spec.template
configurations:
  - transformer.yaml

transformer.yaml:

varReference:
- kind: Deployment
  path: spec/template

foo/deployment.yaml:

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: foo
  labels:
    app: foo
spec:
  selector:
    matchLabels:
      app: foo
  template:
    metadata:
      labels:
        app: foo
    spec:
      containers:
      - image: alpine
        name: foo

bar/deployment.yaml:

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: bar
  labels:
    app: bar
spec:
  selector:
    matchLabels:
      app: bar
  template: $(CUSTOM_TEMPLATE)

[benjamin-bergia]

If your example is the main use case, I would probably go with PodPresets. It's neater and probably going to be easier to manage in the long term than variables. If you need to reference other types of resources, maybe YAML anchors and references? (I didn't test this on kustomize yet, no idea if it works)

[monopole]

@benjamin-bergia good points.

PodPresets/admission controllers/controllers can do pretty much anything. kustomize is a client side alternative to that for generating final config, pre-cluster, for whatever purpose. fwiw, it's not supposed to depend on stuff being installed in the cluster first.

afaik, YAML anchors/references (&'s and *'s) are recognized by go-yaml, and thus transitively supported by kubectl apply via sigs.k8s.io/yaml (ghodss). Presumably there's trouble if a reference appears before an anchor, so anchor placement would determine base ordering, which kustomize must respect, and one can trivially construct impossible arrangement w/ multi-bases. Sometimes it will work, sometimes no. You'd need to run it through a yaml anchor validator to know, or apply it to the cluster to see what happens.

Kustomize vars have the drawback that the un-kustomized config cannot be used in kubectl apply. On the plus side, unlike general Go template vars, kustomize vars represent structured, k8s-cognisant edits - just value replacement via introspection. They are like yaml anchors, but defined outside the yaml being processed, so no reference-before-anchor ordering problem.

var rules are simple, since inventing a programming language is a non-goal of kustomize. All kustomization files in an overlay stack are processed before making a vars replacement pass, and all vars have global scope. so if a base with vars is included multiple times, it will conflict with itself. this could be fixed by introducing a notion of local var, that only applies to the kustomization root in which it is defined (it works down, but not up). We'd need a new term - localvar or something - since existing vars are global.

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