kubeadm: Introduce ValidateSupportedVersion #73474
Conversation
k8s-ci-robot
added
release-note-none
|
|
||
| // TODO: On our way to making the kubeadm API beta and higher, give good user output in case they use an old config file with a new kubeadm version, and | ||
| // tell them how to upgrade. The support matrix will look something like this now and in the future: | ||
| // IsSupportedVersion checks if a supplied GroupVersionKind is not on the list of unsupported GVKs. If it is, an error is returned. |
There was a problem hiding this comment.
this function does not validate Kind. does it make sense for it to accept GV (GroupVersion) instead of GVK?
i would also rename it to IsOldSupportedGroupVersion:
- old because it only handles old versions
- GroupVersion to indicate that it accepts GV
There was a problem hiding this comment.
+1 for the name. Thanks for that! I was feeling kind of awkward with this name.
Yes, judging from the implementation, it is more logical for it to take GroupVersion, but for now every call to it has to be done with gvk.GroupVersion() as a parameter.
There was a problem hiding this comment.
Actually the name probably has to be IsNotOldUnsupportedVersion. I seem to have been missing the old part of it.
There was a problem hiding this comment.
but for now every call to it has to be done with gvk.GroupVersion() as a parameter.
i think we have like 2 calls - one for test and one for init, so it seems fine.
we shouldn't have more, technically.
func IsSupportedVersion(gvk schema.GroupVersionKind) error {
IsSupportedOldVersion also works i guess.
but i think Is... usually implies that the function returns bool.
we probably should print the error on the caller size in inticonfiguration and make it return bool:
errors.Errorf("your configuration file uses an
WDYT?
There was a problem hiding this comment.
Yep, you are right here, but we need to be returned an error. This is a strictly utility function and it should not print directly to the user.
I can rename it to VerifyNotOldUnsupportedVersion and retain the error return. Verify prefixed funcs return errors (and not bools).
There was a problem hiding this comment.
or just name it VerifySupportedVersion which returns an error if it's old and unsupported?
k8s-ci-robot
added
priority/important-longterm
rosti
force-pushed
the
IsSupportedVersion
branch
from
d13bd0d
to
3b8a500
Compare
rosti
changed the title
rosti
force-pushed
the
IsSupportedVersion
branch
from
3b8a500
to
b6d6b48
Compare
|
@rosti: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
k8s-ci-robot
added
the
approved
…rtedVersion DetectUnsupportedVersion is somewhat uncomfortable, complex and inefficient function to use. It takes an entire YAML document as bytes, splits it up to byte slices of the different YAML sub-documents and group-version-kinds and searches through those to detect an unsupported kubeadm config. If such config is detected, the function returns an error, if it is not (i.e. the normal function operation) everything done so far is discarded. This could have been acceptable, if not the fact, that in all cases that this function is called, the YAML document bytes are split up and an iteration on GVK map is performed yet again. Hence, we don't need DetectUnsupportedVersion in its current form as it's inefficient, complex and takes only YAML document bytes. This change replaces DetectUnsupportedVersion with ValidateSupportedVersion, which takes a GroupVersion argument and checks if it is on the list of unsupported config versions. In that case an error is returned. ValidateSupportedVersion relies on the caller to read and split the YAML document and then iterate on its GVK map checking if the particular GroupVersion is supported or not. Signed-off-by: Rostislav M. Georgiev <[email protected]>
rosti
force-pushed
the
IsSupportedVersion
branch
from
b6d6b48
to
e10dcf0
Compare
|
Thanks @rosti! well done! |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini, neolit123, rosti The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Introduce
ValidateSupportedVersionin place ofDetectUnsupportedVersionDetectUnsupportedVersionis somewhat uncomfortable, complex and inefficient function to use. It takes an entire YAML document as bytes, splits it up to byte slices of the different YAML sub-documents and group-version-kinds and searches through those to detect an unsupported kubeadm config. If such config is detected, the function returns an error, if it is not (i.e. the normal function operation) everything done so far is discarded.This could have been acceptable, if not the fact, that in all cases that this function is called, the YAML document bytes are split up and an iteration on GVK map is performed yet again. Hence, we don't need
DetectUnsupportedVersionin its current form as it's inefficient, complex and takes only YAML document bytes.This change replaces
DetectUnsupportedVersionwithValidateSupportedVersion, which takes aGroupVersionargument and checks if it is on the list of unsupported config versions. In that case an error is returned.ValidateSupportedVersionrelies on the caller to read and split the YAML document and then iterate on its GVK map checking if the particularGroupVersionis supported or not.Which issue(s) this PR fixes:
Refs kubernetes/kubeadm#1296
Refs kubernetes/kubeadm#1084
Special notes for your reviewer:
This is a step towards simplifying the config APIs and making them more efficient.
Also, this is a step in introducing the concept of "deprecated config", which is supported config, that can be used at API level and as a source to migrate to the current config (via
kubeadm config migrate), but not create a new cluster from it. This will be done in a future followup PR./cc @kubernetes/sig-cluster-lifecycle-pr-reviews
/area kubeadm
/assign @fabriziopandini
/assign @timothysc
Does this PR introduce a user-facing change?: