Make the apiVersion and kind fields mandatory in Kustomization/Component v1

[koba1t]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

We add the warning message when the apiVersion or kind fields are omitted.

Why is this needed?

Today, kustomize accept to omit the apiVersion and kind fields.
This syntax is easy to start for new users, but it isn't very clear and maybe break the user config when we have a few apiVersion versions (Ex. when we add v1 for apiVersion).

So, Could we consider deprecating this syntax that omits the apiVersion and kind fields?
I think we can start by showing the warning message and adding the auto-fix function. And we can make more consideration to whether remove or not.

Can you accomplish the motivating task without this feature, and if so, how?

Probably, we can decide to use current values (Ex. apiVersion: kustomize.config.k8s.io/v1beta1) when that fields omitted.
These values were hardcoded on codes and we can announce for we require set these values when you need to use v1 and new functions.

But I think we need to add the warning message because we must remove the old apiVersion in the future.

What other solutions have you considered?

Probably, we have enough to add the warning message only.
But if we don't deprecate that, maybe user got to break their config when updating kustomize.

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

[KnVerey]

Thanks for pointing this out--during the period where we support both v1 and v1beta1 versions of our build target types (Kustomization and Component), we will need to be able to distinguish them. I suggest that when we introduce v1, we consider the empty value to be equivalent of v1beta1, and continue to default the kind to Kustomization IFF the version is v1beta1 (explicitly or by default). In other words, v1 must be supplied explicitly, and when it is, kind must be explicit as well. The deprecation and removal of the blank value the becomes synonymous with the deprecation and removal of v1beta1. I think this path would minimize action items for end users.

/retitle Make the apiVersion and kind fields mandatory in Kustomization/Component v1
/triage accepted
/priority important-longterm

[sbin64]

hi @koba1t! Probably, we have enough to add the warning message only. Could be more explicit here? Thanks

[koba1t]

@afzalbin64

Probably, we have enough to add the warning message only. Could be more explicit here? Thanks

It means showing a warning message for stderr when these fields are omitted.

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[koba1t]

/triage accepted