vars replacement overview

[joebowbeer]

Background:

I read in the kustomize v5 release notes and open issue #4049 that the entire vars feature is deprecated, and that we are advised to use replacements instead.

Unfortunately, if I understand correctly, replacements cannot replace all uses of vars, but there are several proposals to address some of the deficits: #3787 #4517

However, even these proposals do not completely fill the gap because they target structured data, whereas vars supports string replacement.

Another issue with replacements is that it does not compose in the same way that vars does, so it may not be possible to replace a Component using vars with one using replacements: #4099 (comment)

Questions:

Is this a fair summary?

What is the strategy for resolving this impasse? I only see a deprecation notice, a partial alternative, and several (incomplete) proposals.

Am I missing something? Where can I find more discussion?

[vugardzhamalov]

I think there was a saying: if KRM function is your sledge hammer then every problem is a nail! Well maybe not exactly, but something along these lines... ;-P

[zs-dima]

+1 replacements are useless for most useful cases, such as domain substitution.
hopefully FluxCD has vars substitution (ArgoCD requares extra sidecar setup for vars substitution)

[webwurst]

Flux supports post build variable substitution.

[zs-dima]

This topic about Kustomize, as I mentioned FluxCD substitution will not help if I will prefer ArgoCD or plain Kustomize

[pre]

A way to define common variables is such a common requirement that all my kustomize based setups (with or without ArgoCD) have always had a companion envsubst mechanism.

it would be great if kustomize offered a mechanism of its own - without having to eg generate an extra configmap just to be able to use the awkward Replacements feature.

[staylorx]

I've also run into this, and I see where vars is powerful, especially when mixed with CI/CD such as ArgoCD. I've become quite fond of the Component and I can imagine a place where the only place to use a variable would be a parameterized Component. That way Kustomization objects can be left as-is, but anything that takes an argument (environment, passed in, piped?) must come through a Component. That those can't be param'd is surprising, and I've struggled with the lack of encapsulation that Components hint at.

[alexrecuenco]

I will preface this by saying that I might be wrong on my assumptions on how replacements is meant to work. From what I understand, it needs an array of every spec of fields it needs to replace written down into its definition, right?

As staylorx says, parametrizing a few fields based on some variable, and then using varReplacements as a configuration to generate a broad set of definitions is quite powerful and intuitive. I can give that to anyone with barely any experience with this entire system, and they very quickly can make modifications, without having to learn the entire toolset.

1. I still don’t quite get how we are meant to replace all places that say $(PROJECTROOTFOLDER) with replacements. The whole prefix thing is very limited, I need to know ahead of time if my variable to replace is before or after a -, and how many - there are on each field I am replacing this variable.
2. It is definitely unintuitive to get replacements to work, and vars are extremely intuitive.
3. I still don’t get how we are meant to write global configurations, so that I don’t need to replicate the fields the replacement is targeting constantly.

It is very verbose to try to achieve a “replace all mentions of $(PROJECTROOTFOLDER)” in a set of non-trivial definitions. With vars generating a Component that contains those definitions and a wide enough config with varReplacements is quite intuitive and does everything you need.

Besides, I believe the deprecation of vars is poorly explained. And I think it is a mistake.

From reading different discussions, I think what happened is that, (And I can’t find the references anymore, please someone help finding those references again)

1. A bug was introduced that allowed using in a properties file a raw name variable without a = sign, and Kustomize would fetch that variable from your bash environment.
2. That bug was later documented as a feature
3. That feature in conjunction with vars can be used for evil. Since the goal here is YAML in, YAML out, with no tricks, and using environment variables kind of defeats the purpose of that.
4. That feature was reverted and a deprecation warning was placed

Now, here, the culprit is not vars. It is the injection of environment variables, vars just happened to play nicely with that.

I think that is why vars was deprecated. I might be wrong, and vars on its own is also evil. But I would love some discussion/explanation of the deprecation and/or a way to use replacements to achieve similar substitution inside variables.

[alexrecuenco]

For example, nameReplacements might be better suited for certain types of interpolations, adding definitions to those.

But what if, as is the case with ArgoCD RBAC, you need to interpolate a text within a field, the pattern is field: “proj:(resourcename):(rolename), …,allow”