Move HPA v2beta2 deprecation to 1.23.

[josephburnett]

What type of PR is this?

/kind cleanup
/kind deprecation

What this PR does / why we need it:

We are creating an HPA v2 stable API to replace the HPA v2beta2 API (kubernetes/enhancements#2702). We have been working toward landing the stable API in v1.22 (tracking doc), the version in which v2beta2 is slated for deprecation. However in the course of creating the new API we have discovered a few places for improvement.

For example, we see an opportunity to create a common meta.v1 ObjectReference to replace the many api-group-specific object references (comment).

And we would like to use the existing meta.v1 Condition instead of the autoscaling-specific conditions. However there is some additional data we need to populate and we need time to figure out how (comment).

Therefore we would like to defer the deprecation of v2beta2 to 1.23 so have time to make this change carefully and improve the ecosystem around us.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

KEP: sig-autoscaling/2702-graduate-hpa-api-to-GA/README.md

[k8s-ci-robot]

@josephburnett: Adding the "do-not-merge/release-note-label-needed" label because no release-note block was detected, please follow our release note process to remove it.

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.

[josephburnett]

/sig autoscaling

[josephburnett]

/triage accepted

[josephburnett]

/release-note-none

[k8s-ci-robot]

@josephburnett: you can not set the release note label to "release-note-none" because the PR has the label "kind/deprecation".

In response to this:

/release-note-none

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.

[fejta-bot]

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.

[josephburnett]

/test pull-kubernetes-e2e-kind

[thockin]

This seems like it should be non-contentious?

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: josephburnett, thockin

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:

• staging/src/k8s.io/api/OWNERS [thockin]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[josephburnett]

Needs lgtm label. And needs "deprecation" label removed (this is an undeprecation).

[mwielgus]

/lgtm

[liggitt]

This seems like it should be non-contentious?

This is extending v2beta2 past https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/1635-prevent-permabeta/

v2beta2 was added in 1.12

The deprecation clock was started in 1.19 as part of https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/1635-prevent-permabeta/

All pre-existing beta API versions were on the clock as of 1.19, and all others did the work to graduate (cronjob, poddisruptionbudget, eviction, etc), or made the decision not to graduate (podsecuritypolicy). The motivation remains to avoid accumulating additional usage on an API version we know will not be around long term.

I think the 1.22 deadline should remain. If more time before GA is needed, a v2beta3 could be reasonable.

[mwielgus]

@liggitt
We made an effort to graduate it 1.22 but additional, unexpected changes were requested (common object reference type in meta). The person working on this didn't manage to get them approved before going for well deserved vacation. He is, however, more than committed to finish everything for 1.23.

This is an unfortunate situation, I fully understand the need of getting apis out of beta, but creating a v2beta3, exactly the same as v2beta2 (or a half-baked GA) with a sole purpose of bypassing the deadline doesn't make sense in my opinion. There is also no person at this moment who can drop everything and do it before the code freeze on Jul 8th (vacation season is starting after months of lockdown). Making v2beta2 deprecated without a proper version will confuse users - they have no other version to go. And they will have to ignore it.

The exceptional move of deprecation marker by one version is, in my opinion, the lesser evil.

[thockin]

Have we decided what we want to do here? I see both sides, for sure, but I worry abut punishing users in this case.

…

On Tue, Jun 29, 2021 at 1:44 AM Marcin Wielgus ***@***.***> wrote: @liggitt <https://github.com/liggitt> We made an effort to graduate it 1.22 but additional, unexpected changes were requested (common object reference type in meta). The person working on this didn't manage to get them approved before going for well deserved vacation. He is, however, more than committed to finish everything for 1.23. This is an unfortunate situation, I fully understand the need of getting apis out of beta, but creating a v2beta3, exactly the same as v2beta2 (or a half-baked GA) with a sole purpose of bypassing the deadline doesn't make sense in my opinion. There is also no person at this moment who can drop everything and do it before the code freeze on Jul 8th (vacation season is starting after months of lockdown). Making v2beta2 deprecated without a proper version will confuse users - they have no other version to go. And they will have to ignore it. The exceptional move of deprecation marker by one version is, in my opinion, the lesser evil. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#103153 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKWAVGKJCPBFMADZE5CF73TVGBXRANCNFSM47HXGJSQ> .

[liggitt]

The reasons for "just one more release" could easily be applied to every beta version that wasn't prioritized and wasn't ready for promotion by the deprecation deadline. Starting a review 3 weeks before code freeze for the release where the beta version is deprecated is too late. I think it is a bad precedent to set to casually lengthen the lifetime and accumulate another 4 months of usage on this version.