Add graduation criteria for CapacityBuffers.#8886
Add graduation criteria for CapacityBuffers.#8886k8s-ci-robot merged 1 commit intokubernetes:masterfrom
Conversation
k8s-ci-robot
added
release-note-none
|
Hi @jbtk. Thanks for your PR. I'm waiting for a github.com 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. DetailsInstructions 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-sigs/prow repository. |
k8s-ci-robot
added
the
size/S
|
As we talked I would like to graduate the CapacityBuffers to beta soon. To ensure that there is clarity about the graduation criteria I am adding a "timeline" to the CapacityBuffers proposal. |
|
|
||
| - [ ] E2e test healthy | ||
| - [ ] In beta for at least 1 full version | ||
| - [ ] Available in at least 1 cloud provider for 3 months |
There was a problem hiding this comment.
I think this isn't broad enough to cover the usecases. Given that this API is a general autoscaling api, more than 1 autoscaler should have support for a couple months before we can graduate. At the minimum 1-2 OSS autoscalers like CAS or Karpenter should support the api.
There was a problem hiding this comment.
Note that there is already 1 OSS implementation in CA OSS which was part of the alpha scope.
|
After some discussion on Slack with @ellistarn and other karpenter maintainers I am changing my proposal to include waiting for karpenter implementation up to some number of versions (to be discussed how many are needed). |
|
Removed e2e test implementation from beta graduation as all of the e2e tests are failing and I do not want to put fixing them on the path to beta. V1 should not happen without e2e tests and there should be enough time to fix them. |
|
|
||
| - [ ] E2e test implemented and healthy | ||
| - [ ] In beta for at least 1 full version | ||
| - [ ] Waiting up to 2 versions in beta for second OSS implementation |
There was a problem hiding this comment.
So you'd target 1.37. While I fully expect us to come to a decision before then, I'd hope we could have a conversation rather than falling back to lazy consensus.
There was a problem hiding this comment.
This is what I was trying to write with "we will reevaluate the graduation criteria with sig-autoscaling leads based on...immediate future plans". So this is not a lazy consensus but a converations with sig-leads. Please let me know what is not clear.
| - [x] Implement the API definition | ||
| - [x] Implement the buffer controller and fake pod processing logic in the cluster autoscaler | ||
|
|
||
| ## Beta graduation criteria (planned for 1.35) |
There was a problem hiding this comment.
Isn't 1.35 more or less closed at this point? I thought it was launching very soon.
There was a problem hiding this comment.
The cluster autoscaler does not do freezes like core kubernetes and releases some time after core kubernetes. I would say there is still a chance (and we will try to do this), but I am not confident that we will make it.
|
After offline discussion changed the wording to 1.37 (inclusive) so the wording is clear. Please reapprove. |
ellistarn
left a comment
ellistarn
left a comment
There was a problem hiding this comment.
Looks good -- thanks for defining this.
|
Looks good to me as well! /lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: DerekFrank, ellistarn, jbtk, towca The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
5 participants
What type of PR is this?
/kind documentation
What this PR does / why we need it:
Add graduation criteria for CapacityBuffers.
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: