kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Follow up comments on sig scalability charter

This commit is contained in:
wojtekt 2018-09-03 12:05:13 +02:00
parent 4075f4d47f
commit f06a86eb12
1 changed files with 8 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
sig-scalability/block_merges.md
View File

@ -7,8 +7,11 @@ from merging into the relevant repos. This document describes the underlying
### Rules of engagement. ### Rules of engagement.
The rules of engagement for blocking merges are as following: The rules of engagement for blocking merges are as following:
- Observe as scalability regression on one of release-blocking test suites. - Observe as scalability regression on one of release-blocking test suites
- Block merges of all PRs. (defined as green to red transition - if tests were already failing, we
don't have a right to declare a regression).
- Block merges of all PRs to the relevant repos in the affected branch,
declaring which repos those are and why.
- Identify the PR which caused the regression: - Identify the PR which caused the regression:
- this can be done by reading code changes, bisecting, debugging based on - this can be done by reading code changes, bisecting, debugging based on
metrics and/or logs, etc. metrics and/or logs, etc.
@ -19,7 +22,7 @@ The rules of engagement for blocking merges are as following:
- reverting the PR - reverting the PR
- switching a feature off (preferably by default, as last resort only in tests) - switching a feature off (preferably by default, as last resort only in tests)
- fixing the problem (if it's easy and quick to fix) - fixing the problem (if it's easy and quick to fix)
- Unblock PR merged. - Unblock merges of all PRs to the relevant repos in the affected branch.
The exact technical mechanisms for it are out of scope for this document. The exact technical mechanisms for it are out of scope for this document.
@ -34,7 +37,8 @@ if we want kubernetes to maintain scalability SLOs. The reasoning is:
- once a regression is merged, and no other action is taken, it is only - once a regression is merged, and no other action is taken, it is only
a matter of time until another regression is merged on top of it, a matter of time until another regression is merged on top of it,
- debugging the cause of two simultaneous (piled-up) regressions is - debugging the cause of two simultaneous (piled-up) regressions is
exponentially harder, see issue 53255 which links to past experience exponentially harder, see issue [53255](http://pr.k8s.io/53255) which
links to past experience
- we need to keep flakiness of merge-blocking jobs very low: - we need to keep flakiness of merge-blocking jobs very low:
- regarding benchmarks, there were several scalability issues in the past - regarding benchmarks, there were several scalability issues in the past
caught by (costly) large-scale e2e tests, which could have been caught and caught by (costly) large-scale e2e tests, which could have been caught and