-
Notifications
You must be signed in to change notification settings - Fork 39.7k
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
Deprecate scheduler AlgorithmSource from v1alpha2 ComponentConfig #87999
Conversation
/hold Next commits will actually remove this field from functional code (if that's the goal right now) |
572a429
to
e346b43
Compare
/hold cancel |
"unsafe" | ||
) | ||
|
||
func Convert_v1alpha2_KubeSchedulerConfiguration_To_config_KubeSchedulerConfiguration(in *v1alpha2.KubeSchedulerConfiguration, out *config.KubeSchedulerConfiguration, s conversion.Scope) error { |
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.
can you add unit tests for both functions?
} | ||
|
||
func Convert_config_KubeSchedulerConfiguration_To_v1alpha2_KubeSchedulerConfiguration(in *config.KubeSchedulerConfiguration, out *v1alpha2.KubeSchedulerConfiguration, s conversion.Scope) error { | ||
out.TypeMeta = in.TypeMeta |
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.
why not use autoConvert_config_KubeSchedulerConfiguration_To_v1alpha2_KubeSchedulerConfiguration
?
out.Plugins = nil | ||
} | ||
out.PluginConfig = *(*[]v1alpha2.PluginConfig)(unsafe.Pointer(&in.PluginConfig)) | ||
return 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.
This one is tricky, but I'm not sure if we should care.
Theoretically, if there is an AlgorithmSource in the internal configuration, we should obtain the diff that needs to be applied to Plugins and Pluginconfig. But this is only needed if someone tries to do something like v1alpha1->internal->v1alpha2.
This is something that can be done by passing --config
in v1alpha1 and --write-config-to
, which writes to v1alpha2 all the time.
Again, should we care? I would say it's not worth the effort.
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.
According to the API conventions, we need to be able to round-trip to older versions without losing any information (see item 4 in this list: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#on-compatibility)
So that brings up a good question, because like you suggested here we can just use the autoConvert function, but how do we handle roundtripping AlgorithmSource? We need to keep that info somewhere (like an annotation?), or we can just drop it once the Scheduler no longer supports AlgorithmSource.
And in this point, how can we get the information from AlgorithmSource that needs to be applied to Plugins and PluginConfig? If it's a configmap, I suppose we could read from that, but if it's a policy file that becomes tougher.
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.
Better information more specific to deprecation here, but I'm still not clear. I think an annotation is the way it suggests? https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api
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.
Though, this api is only in alpha so it might not be relevant for us. I'm ok with just dropping the information too
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.
I would expect the round-trip requirement to be specific to APIs in which multiple clients interact with different versions of the same resource (e.g. REST APIs).
API types used in config files are input-only, and have multiple producers but a single consumer (the component whose configuration they are driving)
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.
I think our policy doesn't cover it while alpha either way.
I think it's confusing at best to have config file formats that are like our api objects but have different rules. I don't have specific case in which they go wrong, though. But I expect the inconsistency will eventually be a problem, e.g. maybe people start making these into CRDs for some strange reason. Anyway, I don't have concerns for this particular change.
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.
In general, these configuration types are not supposed to be outputted. If we could add some type of annotation in them such that no internal->versioned conversion code is auto-generated, that would be a win already.
@@ -0,0 +1,67 @@ | |||
/* |
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.
add conversion_test, but I'm happy to only have v1alpha2->internal
/priority important-longterm |
/retest |
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. |
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.
/approve
/hold
if out.AlgorithmSource.Provider != pointer.StringPtr(v1alpha2.SchedulerDefaultProviderName) { | ||
t.Errorf("expected AlgorithmProvider to be %+v, got %+v", v1alpha2.SchedulerDefaultProviderName, out.AlgorithmSource.Provider) | ||
} | ||
} |
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.
add empty line at the end.
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.
And I believe you still need the exported function that calls the auto function. Just for it to compile.
aad81cd
to
2cd978f
Compare
@alculquicondor no problem, sometimes you can't avoid that. Rebased, please check if I missed anything |
) | ||
|
||
func TestV1alpha2ToConfigKubeSchedulerConfigurationConversion(t *testing.T) { | ||
cases := []struct { |
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.
nit: I don't think we expect more cases, so no need for the cases slice.
/lgtm |
Friendly ping @lavalamp |
@lavalamp PTAL |
@damemi there are new conflicts from the scheduling profiles. Please rebase. |
285eb6f
to
ffe3005
Compare
ffe3005
to
d0d4e9d
Compare
It looks like you need to run |
This commit removes AlgorithmSource from the v1alpha2 scheduler ComponentConfig api. It also creates the necessary manual conversion functions and updates defaulting to accept the change.
d0d4e9d
to
7e1ec59
Compare
/retest |
@@ -39,9 +39,6 @@ const ( | |||
type KubeSchedulerConfiguration struct { | |||
metav1.TypeMeta `json:",inline"` | |||
|
|||
// AlgorithmSource specifies the scheduler algorithm source. |
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.
Removing this will make alpha 1 and 2 not round-trippable. Which is ordinarily OK for alpha, but I thought you were relying on that for some of the other changes?
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.
We only allow users to pass in one configuration (either v1alpha1 or v1alpha2). And then we use the internal types to build profiles.
We have a flag to write the configuration to a file and exit the scheduler. This only has debugging purposes (for kube-scheduler devs), but it would be broken with this change when using v1alpha1 (it only outputs in v1alpha2).
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.
@lavalamp any additional concerns?
/retest |
1 similar comment
/retest |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahg-g, damemi, lavalamp 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 |
/lgtm |
/retest Review the full test history for this PR. Silence the bot with an |
What type of PR is this?
/kind deprecation
What this PR does / why we need it:
Removes
AlgorithmSource
from thev1alpha2
scheduler config API. This field is no longer needed and its removal is the first step toward deprecating policy config in favor of CC.Which issue(s) this PR fixes:
Part of #87526
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: