Kustomize format (add shortcut/docs with apiVersion)

[MPV]

Hi, Would you be open for being on-par with the Kustomize output format?

I.e. this: https://github.com/kubernetes-sigs/kustomize/pull/960

Essentially outputting into filenames containing all of:

• apiVersion
• kind
• metadata.name

Possibly the same as this? {{.apiVersion | lower}}_{{.kind | lower}}_{{.metadata.name | lower}}.yaml

For example: v1_namespace_ns1.yaml ...from:

apiVersion: v1
kind: Namespace
metadata:
  name: ns1

[patrickdappollonio]

Hey @MPV!

Not sure I understand the question, you mean being on par with that out-of-the-box? I would assume so since the current template is:

{{.kind | lower}}-{{.metadata.name}}.yaml

But the suggestion seems to be like you're stating, although not sure how kustomize changes metadata.name if the field is not set...

Just curious, do you have any background and/or behaviour usage that led you to consider this output instead of overwriting it with --template?

(I'm planning, under request, to add an environment variable so you can set it in a CI/CD pipeline once then forget about it).

Would love to know more! My main worry is filename handling, as well as breaking current behaviour (we would have to move to a major version to make sure everyone understands the change).

[patrickdappollonio]

To add to this, I've been looking at how kustomize behaves in certain situations. One of those is #15, where I want to add YAML Patch (while kustomize still supports JSON patch). I have not done it since a) kustomize patching looks a bit different than what I intend to implement; and b) the YAML vs JSON input -- knowing it might be possible to feed JSON patches to the YAML package I plan on using.

[patrickdappollonio]

Another thought... Perhaps I could add --kustomize-template (no parameter value, just a boolean) that would overwrite the output to the one you describe.

Also, curious: consider the following YAML:

apiVersion: v1
kind: Foo
metadata:
  labels: ...
  annotations: ...
spec:
  ...

What would be the kustomize's name? Will it be:

• v1_foo.yaml; or
• v1_foo_.yaml

Knowing the metadata.name field is not present?

Would be good to know what name would it be generated for the case scenario described in #3.

[patrickdappollonio]

@MPV not sure if you've had the time to look into this? Would love to know your feedback!

[patrickdappollonio]

Closing due to lack of feedback. If someone is in need of this feature to be the standard, please feel free to open a new issue!