Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 tasks done
koba1t opened this issue Apr 19, 2023 · 3 comments
Open
2 tasks done
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@koba1t
Copy link
Member

koba1t commented Apr 19, 2023

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! 🎉
@koba1t koba1t added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 19, 2023
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Apr 19, 2023
@natasha41575 natasha41575 added this to To do in Kustomization v1 via automation Apr 19, 2023
@KnVerey
Copy link
Contributor

KnVerey commented May 3, 2023

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

@k8s-ci-robot k8s-ci-robot changed the title Deprecate syntax that omits the apiVersion and kind fields Make the apiVersion and kind fields mandatory in Kustomization/Component v1 May 3, 2023
@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 3, 2023
@afzalbin64
Copy link

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

@koba1t
Copy link
Member Author

koba1t commented Jun 14, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
Development

No branches or pull requests

4 participants