-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
SIG-scalability charter. #1829
SIG-scalability charter. #1829
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: wasylkowski-a Assign the PR to them by writing 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 |
/ok-to-test |
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.
Content of the charter is good, but per some other comments from steering we need to address some basic governance issues like SIG leads. I'd like to see us approve this as it is the substantive content and do another PR to address remaining gaps.
Thanks @wasylkowski-a! +1 to @countspongebob's comment on addressing gaps in a later PR. |
I'm fine with that, but let's add explicit TODOs to the charter to address the issues mentioned in the original PR. |
I will review the two SIG templates (there is a short one and a long one) and propose inclusion into the charter. Would you be ok with a single to-do that covers review of inclusion of the template with all of the relevant items? |
I think that we need a TODO that will describe all the missing parts in the charter. If we mention all the missing things, I'm fine with that. |
I will do that as soon as I get some uninterrupted time; hopefully this week. Stay tuned. |
|
||
## What can we do/require from other SIGs | ||
|
||
*By regression below we mean a regression identified by the set of release-blocking scalability/performance tests (as defined by [the sig-release-x.y-blocking dashboards](https://github.com/kubernetes/test-infra/blob/master/testgrid/config/config.yaml)).* |
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.
https://github.com/kubernetes/test-infra/blob/master/testgrid/config/config.yaml
This page is "not found" :)
Can you fix it?
4. etc | ||
5. once the mitigation is merged to master, unpause the merge queue | ||
|
||
### Rationale |
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.
These are really good points.
One suggestion: put them in the first section to justify the proposal
1. this can be done by reading code changes, bisecting, running A/B tests, etc, | ||
2. we say a PR is identified as the cause when we are reasonably confident that it indeed caused a regression, *even if the mechanism is not 100% understood* - this is because we want to minimize the time of merge queue pause | ||
4. mitigate the regression; this can potentially be different things, e.g.: | ||
1. reverting the PR, |
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 needs to be handled with care to ensure folks are informed of the tradeoff's associated with a revert. kubernetes/kubernetes#60891 (comment) is a good example that blindly reverting without conversing it through can be dangerous.
Same questions as in the previous PR
See https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-requirements.md for the checklist we use to evaluate charters |
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
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. I understand the commands that are listed here. |
I'm going to rewrite it to more match the style SIG Architecture recommend for writing charters. So I'm closing this one and will hopefully open a new one within the next 2 weeks. |
@wasylkowski-a - I don't have persmissions to close this one, so please close :) |
@wojtek-t you should be able to close with the |
/close |
I've opened #2149 as a replacement. |
This is a copy of @porridge's PR #1607. @porridge will no longer be working on that PR, so I am taking it over with his consent.
SIG-scalability leads:
/cc @wojtek-t @countspongebob
Steering committee representatives:
/cc @thockin @smarterclayton @spiffxp