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

WG Reliability charter refinements

This commit is contained in:
wojtekt 2020-10-13 11:00:54 +02:00
parent 74a24a8974
commit 5013172ae2
1 changed files with 25 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
wg-reliability/charter.md
View File

@ -26,21 +26,36 @@ ensuring Kubernetes is stable and reliable.
(e.g. test frameworks) to unblock further steps (e.g. test frameworks) to unblock further steps
- Initiate and drive cross-SIG reliability improvements - Initiate and drive cross-SIG reliability improvements
For all of the above, we will focus on core Kubernetes components and addons.
Other SIG subprojects/components (e.g. SIG Scheduling descheduler) are out of
scope.
### Out of scope ### Out of scope
- Designing and executing improvements clearly falling into individual SIG - Designing and executing on improvements clearly falling into individual SIG
responsibilities. responsibilities.
## Special Powers ## Special Powers
The Reliability WG has a power to block feature-oriented contributions from The Reliability WG will create a proposal that will allow blocking
any SIG if requested reliability-related improvements are not being addressed. feature-oriented contributions from any SIG if requested reliability-related
Before it can be exercised, sig-arch must approve the criteria suggested by improvements are not being addressed. The exact criteria will have to be
this working group. approved by SIG Architecture, SIG Release, SIG Testing and automatically
enforced.
Given WGs are by-definition temporary, on WG Reliability retirement we will The exact scope of blocking hasn't yet been decided. There are at least two
pass this responsibility to to SIG Architecture Production Readiness subproject high-level options: blocking PRs and blocking graduation of features.
or to SIG Architecture generally for reassignment at the leads’ discretion. Conformance vs everything enabled by default has to be explicitly defined).
As a result, the mechanics of blocking hasn't been decided as they will
heavily depend on the exact scope. As mentioned above, all of those will have
to be explicitly approved by SIGs mentioned above.
The blocking criteria (once approved) will be passed to SIG Architecture
Production Readiness subproject or SIG Architecture generally for reassignment
at the lead's discretion.
Note that ideally the criteria should be extendable to other areas (e.g.
security), but that's not the goal by itself.
## Stakeholders ## Stakeholders
@ -64,7 +79,8 @@ involved:
Input on reliability gaps in their areas. Input on reliability gaps in their areas.
The group will be also reaching out to users and cluster operator The group will be also reaching out to users and cluster operator
(e.g. via surveys), to build the full picture. (e.g. via surveys), to build the full picture. We will likely leverage
the CNCF end-user group for this purpose.
In the later phase improving reliability, every single SIG may potentially In the later phase improving reliability, every single SIG may potentially
be involved depending on the findings from the initial phase. be involved depending on the findings from the initial phase.