-
Notifications
You must be signed in to change notification settings - Fork 4.3k
Add graduation criteria for CapacityBuffers. #8886
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
base: master
Are you sure you want to change the base?
Conversation
|
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. 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-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: jbtk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
| - [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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't 1.35 more or less closed at this point? I thought it was launching very soon.
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.: