Deprecate Policy scheduling config

[alculquicondor]

/sig scheduling

As we move forward with graduating component config #89701 (targetting beta for 1.19), Policy APIs are redundant and thus can be removed.

Following API guidelines, we should have a GA alternative for 2 releases. Given current projections, we can remove Policy config in 1.23

[damemi]

This will be related to removing algorithmSource from the internal api (#87526), so just commenting to link these two issues so they're easier to find

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[damemi]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[alculquicondor]

/remove-lifecycle stale

Promotion of component config to GA hopefully happens in 1.22. In the meantime, we have to keep the policy config.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[damemi]

/remove-lifecycle stale

[ahg-g]

Lets try to set a target release to remove policy config and announce that so that users have enough time to migrate.

Do we feel that CC is mature enough to announce policy config deprecation in 1.23? There are more changes coming to CC, but they are properly versioned and moving from beta2->beta3->GA should not be problematic, and probably better than continuing to depend on policy config.

[alculquicondor]

The policy API is already marked as deprecated. Maybe we can add a log line that says when it's going to be removed.

+1 to removal in 1.23

[ahg-g]

Yeah, adding a log line, updating the website docs and sending an email to sig-scheduling and kubernetes-dev google groups.

[ahg-g]

@damemi would you like to follow up on that? Start with announcing on the mailing lists to bring attention to the proposal before we update the logs and docs.

[damemi]

@ahg-g can do, I'll send out the emails later today

[kerthcet]

/cc

[ahg-g]

I think we need a KEP to remove this since it will cause doc updates and whatnot.

[kerthcet]

I'm glad to write the KEP if no one else is working on this. However, since it's my first time to write KEP, I think I will spend more time than familiar ones.

[ahg-g]

sg, @damemi do you want to help @kerthcet through the process?

[damemi]

Sure, @kerthcet the first step is to create an issue in https://github.com/kubernetes/enhancements, and a PR defining your changes following the template provided at https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template (both of these have comments guiding how to fill out each section)

[kerthcet]

Sure, @kerthcet the first step is to create an issue in https://github.com/kubernetes/enhancements, and a PR defining your changes following the template provided at https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template (both of these have comments guiding how to fill out each section)

thanks @damemi, I'll try my best.🥷

[ahg-g]

Actually, instead of creating a new KEP (which I am not sure what we will put in it on its own), how about we piggyback on the CC KEP and v1beta3 graduation? The idea is to have a KEP that references the deprecation and allows us to update the docs.

[damemi]

Yeah this could be added to the CC deprecation KEP under the section describing v1beta3 https://github.com/kubernetes/enhancements/pull/2850/files#diff-535abc4c1be084f369a0b7a4951db2258d840f1657e331d0c4c6c13d537cc949R100

[kerthcet]

Actually, instead of creating a new KEP (which I am not sure what we will put in it on its own), how about we piggyback on the CC KEP and v1beta3 graduation? The idea is to have a KEP that references the deprecation and allows us to update the docs.

yes, it's also convinced, since it's part of the lifecycle of a new feature. However, I'll still work on this kep, on the one hand to walk through a completely cycle of kep, on the other hand, if we open our arms again, I think it will play a role.

[kerthcet]

If reopen the former kep is accepted, I'll keep these two keps in sync. And after I finished, I'll close the new one. maybe I will need a help from @damemi to review my kep and give me some advice.

[ahg-g]

I don't think we need a standalone KEP, you will have other chances to learn the process :)

We also need to mark v1beta1 deprecated as part of v1beta3 graduation. Since we are getting closer to the KEP deadline, @damemi do you want to send an update to the KEP? I can send it too.

[damemi]

I think @kerthcet can update the KEP, I don't want to take that.

@kerthcet what you need to do is open a PR in github.com/kubernetes/enhancements updating keps/sig-scheduling/785-scheduler-component-config-api/README.md to note:

• Policy config is deprecated
• v1beta1 is deprecated

These will be under the v1beta3 section I linked to above. Does that sound good? If not, I can do it

[kerthcet]

I don't think we need a standalone KEP, you will have other chances to learn the process :)

We also need to mark v1beta1 deprecated as part of v1beta3 graduation. Since we are getting closer to the KEP deadline, @damemi do you want to send an update to the KEP? I can send it too.

sounds good. I'll close the kep.

[kerthcet]

I think @kerthcet can update the KEP, I don't want to take that.

@kerthcet what you need to do is open a PR in github.com/kubernetes/enhancements updating keps/sig-scheduling/785-scheduler-component-config-api/README.md to note:

• Policy config is deprecated
• v1beta1 is deprecated

These will be under the v1beta3 section I linked to above. Does that sound good? If not, I can do it

yeah, I'm glad to, thanks @damemi

[ahg-g]

/assign @damemi

[damemi]

/assign @kerthcet
xref kubernetes/enhancements#2901 and #104782