proposal: bases can define input arguments that can be passed by overlays & support for mixins

[govinda-attal]

Dear kustomize team,

I am keen to know if this is supported in kustomize or else putting forward a proposal

Proposal:
base to support arguments (may or may not be called as 'variables'); that can be passed as input arguments by overlays.

This can help to achieve super-dry bases and composition of bases & overlays, to simplify kustomization.

I tried to achieve this with help of existing vars but face certain limitations.

To layout the context.
base/kustomize.yaml defines certain variables which refers to fields within cfg-x.yaml

app1/kustomize.yaml uses base and defines strategic merge patch to override variables from base. Also defines it additional app1 vars. No dramas, works well. The patch is able to override base_vars.

Now app2/kustomize.yaml uses base and defines strategic merge patch to override variables from base. Also defines it additional app2 vars. No dramas, works well. The patch is able to override base_vars.

Now composed-app as an overlay is composed of app1 & app2. It will also use strategic merge to patch variables. for base, app1, and app2.

Now kustomize will error out - as per its design as:
(1) resource by identifier - cfg-x ... already defined (because of app1 & app2 depending on same base which defines resource cfg-x).
(2) say, I work around this by overriding name of cfg-x within app1 & app2 with json 6902 patches - after that I will get an error that variable (defined in base) used in app1 and app2 is already encountered and hence cannot be redefined in app2.

Forgive, if this is totally in-appropriate understanding of kustomize.

Appreciate that to define currently a variable, we need a resource which needs to be unique. Could it be relaxed?
In doing so, workarounds like changing the name of the resource (from which variables are defined) is not needed when same base is used by multiple overlays and then composed within a unified app like above.

This makes me ponder should kustomize support a different construct of input arguments as opposed to variables.

This i think can be said as somehow related to #759

However, the need highlighted here is of input arguments.

Would be happy to hear your thoughts.

[govinda-attal]

https://github.com/govinda-attal/kustomize-vars
This is a sample repo that goes along with the description above.

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