Allow for per-version kustomize options

[snuggie12]

Summary

Whatever is passed into data.kustomize.buildOptions is universally applied to all versions of kustomize. If you use an option from a newer version that doesn't exist on an older version you'll get errors for that application.

Motivation

I believe kustomize 3.9.2 introduced --enable_kyaml=true as the default. It also has the chart inflator as a builtin plugin so it eliminates the need for the custom config management plugin "kustomized-helm". However, this option doesn't exist in older versions such as 3.5.X and we have a few apps that needed that.

Proposal

IDK if this breaks backwards compatibility, but was thinking you could change data.kustomize.version.v3.5.1 to be data.kustomize.version.v3.5.1.path and add the possibility of data.kustomize.version.v3.5.1.buildOptions.

[alexmt]

Thank you for the proposal @snuggie12 , I think we should prioritize it to enable upgrading to the latest 3.x kustomize.

The data.kustomize.version.v3.5.1.path looks good but it introduces ambiguity. It is unclear if the user wanted to specify version v3.5.1.path or version v3.5.1 and some path.

How about if we support kustomize.path.<version> and kustomize.buildOptions.<version> keys. The kustomize.version.<version> should be deprecated but supported for backward compatibility:

data:
  # default kustomize build options
  kustomize.buildOptions: --load_restrictor none

  # register one more kustomize version
  kustomize.path.v3.9.1: /usr/local/bin/kustomize-3.9.1
  # specifies build options for new kustomize verison
  kustomize.buildOptions.v3.9.1: `--enable_kyaml=true`

What do you think?

[snuggie12]

Oh yeah, much better idea.

They actually just released 4.x in kind of a hurry due to licensing issues. However, I think it's 3.9.2 that will give you all issues because yaml that was accepted before is not now. Good luck with that fun.

[chetan-rns]

Can I pick this issue? Happy to raise a PR :)

[jannfis]

Thanks Chetan, much appreciated!

[jannfis]

@chetan-rns Just as a heads-up, Kustomize also changed the syntax for some of their add label (and I believe, add annotation) command line options, as noted in #5007 (comment)

Maybe we can consider a knob for this with this change as well? Unfortunately, I cannot find the related change/PR in Kustomize's repository anymore, but I believe it must have changed somewhere between v3.8.1 and v3.8.9 (yes, that's within a patch release)

[chetan-rns]

Thanks for the heads up, will take a look