Kustomize: Support for variable replacement in literals

[dsyer]

Currently, to get an env var to point to a service name, I have to do this (which makes the k8s resource into a template - the famous anti-pattern that no-one wanted but we ended up with anyway):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    spec:
      containers:
      - name: app
        env:
        - name: MYSQL_HOST
          value: $(MYSQL_SERVICE_NAME)

I also had to create an env entry in my Deployment that I didn't really want - I prefer to use a ConfigMap. What I would like is to put that placeholder in kustomization.yaml via a literal (or similar):

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base
configMapGenerator:
  - name: env-config
    behavior: merge
    literals:
      - MYSQL_HOST=$(MYSQL_SERVICE_NAME)
vars:
  - name: MYSQL_SERVICE_NAME
    objref:
      apiVersion: v1
      kind: Service
      name: mysql

The vars can even go in the base if I don't want it here.

[tkellen]

Dupe of: https://github.com/kubernetes-sigs/kustomize/issues/318.
Also see: https://github.com/kubernetes-sigs/kustomize/pull/1620#issuecomment-542375406

It would probably be best if you avoided this rabbit hole and just used envsubst instead.

[tkellen]

At this point a real contribution around vars to this project would be a PR that adds loudly to the documentation how broken vars are and encourages folks to consider this responsibility (var handling, any sort of templating at all) outside the scope of kustomize.

[dsyer]

I'm not sure I understand, but I'm not really very deep in any rabbit hole right now. Maybe you can spare some time to explain a bit more to someone who doesn't have as good an understanding of how kustomize works.

My reading of #318 was that it is about something different (I did find that one before I opened this issue). Isn't it? It says it's about literals as the value of vars. Maybe it morphed into something else and I didn't spot it. I'm afraid reading the whole of #1620 and #1600 didn't help me either to understand the problem better or solve it.

I would appreciate any help anyone can give getting my example to work (i.e. extracting a service name, which is actually needed by another deployment, and has been generated by kustomize, so I don't know what it is in advance). I doubt I can do that with envsubst, but I'm open to being educated.

[bkuschel]

Variables are only "bound" in the output resources as a final step after the top level build has finished, even if declared in a child build. What this means is that any variables that are "consumed" by transformers/generators as input that don't have a direct representation in the final output are never substituted.
Further, variable substitution is only performed on output resources, since you are using a transformer and never outputting it as a resource from a build (which is not possible through builtins, which are executed directly as generators or transformers), they would never get substituted, regardless.

We are preparing a PR which binds variables immediately where the variable is declared, which will only help sin your scenario if you create a separate resources for the transformer and process them as resources first that have the vars you want substituted.

[bkuschel]

Here is a transformer we created that does kustomize child level build var substitution. It has some examples.
https://github.com/qlik-oss/kustomize-plugins/tree/master/kustomize/plugin/qlik.com/v1/supervars

PR just pushed here: https://github.com/kubernetes-sigs/kustomize/pull/1738

[bkuschel]

@dsyer actually, in your example the literal _does_ get passed through but its not included in the varRefences. You need to create a configuration with a new varReferences that contains the kind 'ConfigMap' and path to your variable.
example:
varreferences.yaml:

- path: data/MYSQL_HOST
  kind: ConfigMap

kustomization.yaml:

configurations:
  - varreference.yaml

[dsyer]

That was helpful, and I didn't understand your first comment at all, so thanks for taking the time. If anyone else is trying it, I think varreferences.yaml has to be:

varReference:
- path: data/MYSQL_HOST
  kind: ConfigMap

[jbrette]

@dsyer @bkuschel Have a look at that example.

We did withdraw the PRs solving the needs you are describing the day we were told that VAR will be removed altogether from kustomize support.

Famous and very simple #506 use case is also solved too: https://github.com/keleustes/kustomize/tree/allinone/examples/issues/issue_0506.

Now we are waiting for the "replacement" PR to work, what is interesting it has fundamentally the exact same issue on when to resolve the "replacement/inline": at the local kustomization context or the local. Until then we have to maintain a fork that allows us to do things, not spend ages working around kustomize limitation or have kustomization.yaml which are too big to manage.

[bkuschel]

@dsyer sorry for the ramble. Basically secretGenerator will not work for your example.

[bkuschel]

@jbrette The variable collision problem is a consequence of the current design, which only declares the binding and doesn’t do the substitution at the child build level, only at the very end. So, which binding to use is not a problem if you substitute the value where the binding is declared and reconcile the values further upstream. (Using name reference substitution, for example)
Perhaps somebody could explain the rationale behind the current design. It is very hard and cumbersome to work with in a micro service topology, especially if you want to support independent service manifest generation.

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

[tkellen]

/reopen
/remove-lifecycle-rotten

This project really needs to be removed from kubectl if it is not under active development.

[k8s-ci-robot]

@tkellen: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen
/remove-lifecycle-rotten

This project really needs to be removed from kubectl if it is not under active development.

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.