-
Notifications
You must be signed in to change notification settings - Fork 38.9k
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
Fix API encoding inconsistencies in KubeSchedulerConfig #91625
Fix API encoding inconsistencies in KubeSchedulerConfig #91625
Conversation
Hi @pancernik. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
/cc @alculquicondor |
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
/ok-to-test |
@@ -102,7 +102,7 @@ type KubeSchedulerConfiguration struct { | |||
// Extenders are the list of scheduler extenders, each holding the values of how to communicate | |||
// with the extender. These extenders are shared by all scheduler profiles. | |||
// +listType=set | |||
Extenders []v1.Extender `json:"extenders,omitempty"` | |||
Extenders []Extender `json:"extenders,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this means we currently have two Extenders
copies in v1 and v1beta1, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, Policy
includes the old type. It will be removed once KubeSchedulerConfiguration
fully replaces Policy
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we graduation KubeSchedulerConfiguration to GA, we can rename v1.Extender
to v1.DeprecatedExtender
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is super subtle... can we name this more clearly to make sure we don't use the wrong struct and flip encoding of the enableHttps field?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we can rename the v1.Extender type later, then we can rename it now, if so, lets do it in this PR (perhaps we can using Legacy instead of Deprecated).
/test pull-kubernetes-kubemark-e2e-gce-big |
/test pull-kubernetes-e2e-gce-100-performance |
@@ -102,7 +102,7 @@ type KubeSchedulerConfiguration struct { | |||
// Extenders are the list of scheduler extenders, each holding the values of how to communicate | |||
// with the extender. These extenders are shared by all scheduler profiles. | |||
// +listType=set | |||
Extenders []v1.Extender `json:"extenders,omitempty"` | |||
Extenders []Extender `json:"extenders,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once we graduation KubeSchedulerConfiguration to GA, we can rename v1.Extender
to v1.DeprecatedExtender
.
if err := autoConvert_config_Extender_To_v1beta1_Extender(in, out, s); err != nil { | ||
return err | ||
} | ||
out.HTTPTimeout.Duration = in.HTTPTimeout |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liggitt why is this not handled by the generated conversion? Is it an anti-pattern to use time.Duration as the internal type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, I had a feeling that it should be handled there.
Other parts of k8s use metav1.Duration
in internal type which offers no advantages over time.Duration
apart of autoconvert.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use metav1.Duration in API type fields
out.BindVerb = in.BindVerb | ||
out.EnableHTTPS = in.EnableHTTPS | ||
out.TLSConfig = (*config.ExtenderTLSConfig)(unsafe.Pointer(in.TLSConfig)) | ||
// WARNING: in.HTTPTimeout requires manual conversion: inconvertible types (k8s.io/apimachinery/pkg/apis/meta/v1.Duration vs time.Duration) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use meta/v1.Duration internally and avoid a manual conversion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will still need to do a manual conversion from v1.Extender
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
duplicate the type in pkg/scheduler/apis/config/types.go
renaming the existing one as LegacyExtender
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, that might not work, please check... but you can do the "manual" conversion in the type that will eventually go away in v1 folder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we duplicated Extender
as LegacyExtender
, we would still have to maintain a translation between them as we would use only one internally. I think it's better to do the manual conversion from v1.LegacyExtender
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
correct, only one internally and do manual conversion from the legacy one.
Please follow the suggestion here regarding release notes #91580 (comment) |
f6cb1a7
to
f94b358
Compare
bc1a62c
to
4ef2c9c
Compare
/retest |
4ef2c9c
to
d2ec07d
Compare
/test pull-kubernetes-integration |
if err := Convert_v1_ExtenderTLSConfig_To_config_ExtenderTLSConfig(in.TLSConfig, out.TLSConfig, s); err != nil { | ||
return err | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC, generated code also adds:
else {
out.TLSConfig = nil
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
/test pull-kubernetes-integration |
/retest |
lgtm, but will stamp after @liggitt's approval and squash |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alculquicondor, liggitt, pancernik 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 |
26719b4
to
d7c84e1
Compare
/test pull-kubernetes-e2e-kind-ipv6 |
/lgtm |
/sig scheduling |
/remove-sig scheduling |
/sig scheduling clearly, there is a bug in the bot |
What type of PR is this?
/kind api-change
What this PR does / why we need it:
v1
SchedulerPolicy
config includesExtender
type with an inconsistent API encoding.We fix it by
Extender
type with a correct API encoding inv1beta1
KubeSchedulerConfiguraton
Which issue(s) this PR fixes:
Fixes #65414
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: