From b0f09059a3b7ece7494df7739497a99aaf1417a3 Mon Sep 17 00:00:00 2001 From: Derek Carr Date: Mon, 9 Apr 2018 23:09:32 -0400 Subject: [PATCH 1/2] [RFC] SIG-Node initial charter --- sig-node/README.md | 15 ++-- sig-node/charter.md | 214 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 222 insertions(+), 7 deletions(-) create mode 100644 sig-node/charter.md diff --git a/sig-node/README.md b/sig-node/README.md index 6c82f2280f5..5935b43f474 100644 --- a/sig-node/README.md +++ b/sig-node/README.md @@ -77,19 +77,20 @@ Monitor these for Github activity if you are not a member of the team. ## Goals -Topics include, but are not limited to: +The following topics fall under scope of this SIG. * Kubelet related features (e.g. Pod lifecycle) * Node level performance and scalability (with [sig-scalability](../sig-scalability)) -* Node reliability +* Node reliability (prooblem detection and remediation) * Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle)) -* Container runtimes: docker, [rkt](../sig-rktnetes), etc. +* Container runtimes +* Device management * Images, package management -* Resource management (with [sig-scheduling](../sig-scheduling)) -* Issues related to monitoring (with [sig-instrumentation](../sig-instrumentation)) +* Host resource management (with [sig-scheduling](../sig-scheduling)) +* Hardware discovery +* Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation)) * Node level security and Pod isolation (with [sig-auth](../sig-auth)) -* Kernel interactions (to a limited extent) -* ... +* Host OS and/or kernel interactions (to a limited extent) We also work closely with [sig-storage](../sig-storage) and [sig-network](../sig-network). As you can see, this is a very cross-functional team! diff --git a/sig-node/charter.md b/sig-node/charter.md new file mode 100644 index 00000000000..1ef64833037 --- /dev/null +++ b/sig-node/charter.md @@ -0,0 +1,214 @@ +# SIG Node Governance + +## Scope + +SIG Node is responsible for the components that support the controlled +interactions between pods and host resources. We manage the lifecycle of pods +that are scheduled to a node. We focus on enabling a broad set of workload +types, including hardware and performance sensitive workloads. We maintain +isolation boundaries between pods on a node, as well as the pod and the host. We +aim to continuously improve node reliability. + +### In scope + +The following topics fall under ownership of this SIG. + +* Kubelet related features (e.g. Pod lifecycle) +* Node level performance and scalability (with [sig-scalability](../sig-scalability)) +* Node reliability (prooblem detection and remediation) +* Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle)) +* Container runtimes +* Device management +* Images, package management +* Host resource management (with [sig-scheduling](../sig-scheduling)) +* Hardware discovery +* Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation)) +* Node level security and Pod isolation (with [sig-auth](../sig-auth)) +* Host OS and/or kernel interactions (to a limited extent) + +### Out of scope + +The following topics are out of the scope of this SIG + +* network management +* persistent storage management + +## Roles + +Membership for roles tracked in: [OWNERS] + +- **Chairs** + - Run operations and processes governing the SIG + - *MUST* remain active in the role and are removed from the position if they + are unresponsive for > 3 months and *MAY* be removed if not proactively + working with other chairs to fulfill responsibilities. To remove an + inactive chair, a majority vote from existing chairs should occur. If a + [super-majority] is not possible, the [steering-committee] may sponsor + removal. + - *MAY* declare an intention to take sabbatical for no more than 3 months in a + calendar year. Chairs should notify existing chairs of their intent, and + absent at least 2 remaining chairs, *MUST* nominate a temporary replacement + from the existing set of technical leads during this period. + - *SHOULD* represent a diverse set of organizations. This is predicated on + interest in the role from multiple organizations with qualified candidates. + Qualification is measured by existing chairs and *SHOULD* be supported by a + majority of SIG Members under [lazy-consensus]. + - *MAY* decide to step down at any time and propose a replacement. Use lazy + consensus amongst chairs with fallback on majority vote to accept proposal. + This *SHOULD* be supported by a majority of SIG Members. + - *MAY* select additional chairs through a [super-majority] vote amongst + chairs. This *SHOULD* be supported by a majority of SIG Members. + - Number: 1-3 + - Defined in [sigs.yaml] + +- **Technical Leads** + - Technical leads seeded by legacy SIG chairs from subproject owners + - Establish new subprojects + - Decommission existing subprojects + - Sponsor working groups + - End of life working groups + - *MUST* ensure that all areas of the SIG (including those that fall outside + subprojects) have active owners. + - *MAY* set SIG milestone priorities. + - *SHOULD* act as an escalation point for technical disputes in subprojects. + - *MUST* resolve issues impacting multiple subprojects in the SIG. + - *SHOULD* meet or communicate regularly enough to ensure they are aligned. + Decisions made by technical leads should be consistent across the SIG. If + technical leads are providing inconsistent direction, then they *MUST* align + themselves. + - *MAY* select additional tech leads through a [super-majority] vote amongst + tech leads and chairs. This *SHOULD* be supported by a majority of SIG + Members under [lazy-consensus]. + - *SHOULD* represent a diverse set of organizations. This is predicated on + interest in the role from multiple organizations with qualified candidates. + - *MUST* remain active in the role and are automatically removed from the + position if they are unresponsive for > 3 months and *MAY* be removed if not + proactively working with other technical leads to fulfill responsibilities. + Removal of a technical lead requires [super-majority] vote amongst tech + leads and chairs. + - *MAY* declare an intention to take sabbatical for no more than 3 months in a + calendar year. Chairs should notify existing chairs of their intent, and + absent at least 2 remaining chairs, *MUST* nominate a temporary replacement + from the existing set of technical leads during this period. + - Technical Leads *SHOULD* represent a diverse set of organizations. This is + predicated on interest in the role from multiple organizations with + qualified candidates. + - *SHOULD* have a record of consistent solid technical judgement and + leadership over a sustained period especially over areas for which they are + the de-facto lead + - Number: 3-7 + - Defined in [sigs.yaml] and [OWNERS] files + +- **Subproject Owners** + - Scoped to a subproject defined in [sigs.yaml] + - Seed subproject owners *MAY* include initial proposal author(s) and/or Tech + Leads + - *MUST* be an escalation point for technical decisions and failing or flaky + tests in the subproject + - *MUST* proactively maintain the subproject health and status or delegate + this responsibility. For actively developed projects, this *SHOULD* include + setting milestone priorities, tracking release bits, and ensure adequate + test coverage. For maintenance mode projects, this *SHOULD* include + maintaining test health and ensuring compatibility with new features. + - *MUST* remain active in the role and are automatically removed from the + position if they are unresponsive for > 3 months. + - *MAY* declare an intention to take sabbatical for no more than 3 months in a + calendar year. Should notify existing owners of their intent, and *MAY* + nominate a temporary replacement from the existing set of owners during this + period. + - *SHOULD* have a record of consistent solid technical judgement over a + sustained period, especially over areas for which they are the owner + - *MAY* be removed if not proactively working with other Subproject Owners to + fulfill responsibilities. + - *MAY* decide to step down at any time and propose a replacement. Use + [lazy-consensus] amongst subproject owners with fallback on majority vote to + accept proposal. This *SHOULD* be supported by a majority of subproject + contributors (those having some role in the subproject). + - *MAY* select additional subproject owners through a [super-majority] vote + amongst subproject owners. This *SHOULD* be supported by a majority of + subproject contributors (through [lazy-consensus] with fallback on voting). + - *SHOULD* work to ensure technical excellence within area + - actively work to reduce complexity of the area + - define general acceptance criteria for work as needed (code, test, + documentation guidelines, etc) + - consider cross-project interactions in technical decisions + - prioritize urgent issues appropriately (e.g. addressing critical bugs, + security vulnerabilities, or test failures) + - Number: 1-7 per subproject (depending on size and scope) + - Defined in [sigs.yaml] [OWNERS] files + +- Members + - *MUST* maintain health of at least one subproject or the health of the SIG + - *MUST* show sustained contributions to at least one subproject or to the SIG + - *SHOULD* hold some documented role or responsibility in the SIG and / or at + least one subproject (e.g. reviewer, approver, etc) + - *MAY* build new functionality for subprojects + - *MAY* participate in decision making for the subprojects they hold roles in + - *SHOULD* include all reviewers and approvers in [OWNERS] files for + subprojects + - *MUST* remain active in the role and may be removed from the position if + they are unresponsive for > 1 year. + - *MAY* be removed if not proactively working with other Subproject Owners to + fulfill responsibilities. + +## Organizational management + +- SIG meets weekly on [zoom] with [agenda in meeting notes] + - *SHOULD* be facilitated by chairs unless delegated to specific Members +- SIG overview and deep-dive sessions organized for Kubecon + - *SHOULD* be organized by chairs unless delegated to specific Members + +- Contributing instructions defined in the SIG CONTRIBUTING.md + +### Project management + +#### Subproject creation + +- Subprojects *MAY* be created by [KEP] proposal and *MUST* be approved by at + least 1 tech lead, and accepted by [lazy-consensus] with fallback on majority + vote of SIG Technical Leads. The result *SHOULD* be supported by the majority + of SIG members. + - KEP *MUST* establish subproject owners + - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] + files with subproject owners + - Where subprojects processes differ from the SIG, they must document how + - e.g. if subprojects release separately - they must document how release + and planning is performed + - Subprojects may not be seeded from existing repositories pending CNCF + process definition + +### Technical processes + +Subprojects of the SIG *MUST* use the following processes unless explicitly +following alternatives they have defined. + +- Proposing and making decisions + - Proposals *SHOULD* be sent as [KEP] PRs and published to + [kubernetes-sig-node] as an announcement + - Proposals *MUST* be presented and discussed in at least 1 SIG node meeting + - If the authors are unable to attend, another community member can be found + to champion the proposal. + - Proposals *SHOULD* follow [KEP] decision making process + - For proposed extensions to a subproject, the subproject *MUST* be + identified in the KEP, and approvers *MUST* include subproject owners + +- Test health + - Canonical health of code published to [testgrid] + - Consistently broken tests automatically send an alert to + [kubernetes-sig-node-test-failures] + - SIG members are responsible for responding to broken tests alert. PRs that + break tests should be rolled back if not fixed within 1 business day. + - Test dashboard checked and reviewed at start of each SIG meeting. Owners + assigned for any broken tests and followed up during the next SIG meeting. + +[steering-committee]: https://github.com/kubernetes/community/blob/master/committee-steering/OWNERS +[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus +[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote +[KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md +[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml +[OWNERS]: https://github.com/kubernetes/community/blob/master/sig-auth/OWNERS +[agenda and meeting notes]: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit +[zoom]: https://zoom.us/j/4799874685 +[testgrid]: https://k8s-testgrid.appspot.com/sig-node#Summary +[kubernetes-sig-node]: https://groups.google.com/forum/#!forum/kubernetes-sig-node +[kubernetes-sig-node-test-failures]: https://groups.google.com/forum/#!forum/kubernetes-sig-node-test-failures \ No newline at end of file From 1efc194aa38697772cb90c7dc41d1ebf8fca0172 Mon Sep 17 00:00:00 2001 From: Derek Carr Date: Wed, 1 Aug 2018 10:05:19 -0400 Subject: [PATCH 2/2] update per common charter template --- sig-node/README.md | 27 +++-- sig-node/charter.md | 261 +++++++++++--------------------------------- 2 files changed, 76 insertions(+), 212 deletions(-) diff --git a/sig-node/README.md b/sig-node/README.md index 5935b43f474..e1bde974915 100644 --- a/sig-node/README.md +++ b/sig-node/README.md @@ -79,18 +79,21 @@ Monitor these for Github activity if you are not a member of the team. The following topics fall under scope of this SIG. -* Kubelet related features (e.g. Pod lifecycle) -* Node level performance and scalability (with [sig-scalability](../sig-scalability)) -* Node reliability (prooblem detection and remediation) -* Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle)) -* Container runtimes -* Device management -* Images, package management -* Host resource management (with [sig-scheduling](../sig-scheduling)) -* Hardware discovery -* Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation)) -* Node level security and Pod isolation (with [sig-auth](../sig-auth)) -* Host OS and/or kernel interactions (to a limited extent) +- Kubelet and its features +- Pod API and Pod behaviors (with [sig-architecture](../sig-architecture)) +- Node API (with [sig-architecture](../sig-architecture)) +- Node controller +- Node level performance and scalability (with [sig-scalability](../sig-scalability)) +- Node reliability (problem detection and remediation) +- Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle)) +- Container runtimes +- Device management +- Image management +- Node-level resource management (with [sig-scheduling](../sig-scheduling)) +- Hardware discovery +- Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation)) +- Node level security and Pod isolation (with [sig-auth](../sig-auth)) +- Host OS and/or kernel interactions (to a limited extent) We also work closely with [sig-storage](../sig-storage) and [sig-network](../sig-network). As you can see, this is a very cross-functional team! diff --git a/sig-node/charter.md b/sig-node/charter.md index 1ef64833037..4150b6058de 100644 --- a/sig-node/charter.md +++ b/sig-node/charter.md @@ -1,214 +1,75 @@ -# SIG Node Governance +# SIG Node Charter + +This charter adheres to the conventions described in the [Kubernetes Charter README] and uses +the Roles and Organization Management outlined in [sig-governance]. ## Scope SIG Node is responsible for the components that support the controlled interactions between pods and host resources. We manage the lifecycle of pods that are scheduled to a node. We focus on enabling a broad set of workload -types, including hardware and performance sensitive workloads. We maintain +types, including workloads with hardware specific or performance sensitive requirements. We maintain isolation boundaries between pods on a node, as well as the pod and the host. We aim to continuously improve node reliability. ### In scope -The following topics fall under ownership of this SIG. - -* Kubelet related features (e.g. Pod lifecycle) -* Node level performance and scalability (with [sig-scalability](../sig-scalability)) -* Node reliability (prooblem detection and remediation) -* Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle)) -* Container runtimes -* Device management -* Images, package management -* Host resource management (with [sig-scheduling](../sig-scheduling)) -* Hardware discovery -* Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation)) -* Node level security and Pod isolation (with [sig-auth](../sig-auth)) -* Host OS and/or kernel interactions (to a limited extent) +SIG [readme] + +#### Code, Binaries and Services + +- Kubelet and its features +- Pod API and Pod behaviors (with [sig-architecture](../sig-architecture)) +- Node API (with [sig-architecture](../sig-architecture)) +- Node controller +- Node level performance and scalability (with [sig-scalability](../sig-scalability)) +- Node reliability (problem detection and remediation) +- Node lifecycle management (with [sig-cluster-lifecycle](../sig-cluster-lifecycle)) +- Container runtimes +- Device management +- Image management +- Node-level resource management (with [sig-scheduling](../sig-scheduling)) +- Hardware discovery +- Issues related to node, pod, container monitoring (with [sig-instrumentation](../sig-instrumentation)) +- Node level security and Pod isolation (with [sig-auth](../sig-auth)) +- Host OS and/or kernel interactions (to a limited extent) + +#### Cross-cutting and Externally Facing Processes + +- CRI [validation] and [testing policy] +- Node [test grid] and [perf dashboard] ### Out of scope -The following topics are out of the scope of this SIG - -* network management -* persistent storage management - -## Roles - -Membership for roles tracked in: [OWNERS] - -- **Chairs** - - Run operations and processes governing the SIG - - *MUST* remain active in the role and are removed from the position if they - are unresponsive for > 3 months and *MAY* be removed if not proactively - working with other chairs to fulfill responsibilities. To remove an - inactive chair, a majority vote from existing chairs should occur. If a - [super-majority] is not possible, the [steering-committee] may sponsor - removal. - - *MAY* declare an intention to take sabbatical for no more than 3 months in a - calendar year. Chairs should notify existing chairs of their intent, and - absent at least 2 remaining chairs, *MUST* nominate a temporary replacement - from the existing set of technical leads during this period. - - *SHOULD* represent a diverse set of organizations. This is predicated on - interest in the role from multiple organizations with qualified candidates. - Qualification is measured by existing chairs and *SHOULD* be supported by a - majority of SIG Members under [lazy-consensus]. - - *MAY* decide to step down at any time and propose a replacement. Use lazy - consensus amongst chairs with fallback on majority vote to accept proposal. - This *SHOULD* be supported by a majority of SIG Members. - - *MAY* select additional chairs through a [super-majority] vote amongst - chairs. This *SHOULD* be supported by a majority of SIG Members. - - Number: 1-3 - - Defined in [sigs.yaml] - -- **Technical Leads** - - Technical leads seeded by legacy SIG chairs from subproject owners - - Establish new subprojects - - Decommission existing subprojects - - Sponsor working groups - - End of life working groups - - *MUST* ensure that all areas of the SIG (including those that fall outside - subprojects) have active owners. - - *MAY* set SIG milestone priorities. - - *SHOULD* act as an escalation point for technical disputes in subprojects. - - *MUST* resolve issues impacting multiple subprojects in the SIG. - - *SHOULD* meet or communicate regularly enough to ensure they are aligned. - Decisions made by technical leads should be consistent across the SIG. If - technical leads are providing inconsistent direction, then they *MUST* align - themselves. - - *MAY* select additional tech leads through a [super-majority] vote amongst - tech leads and chairs. This *SHOULD* be supported by a majority of SIG - Members under [lazy-consensus]. - - *SHOULD* represent a diverse set of organizations. This is predicated on - interest in the role from multiple organizations with qualified candidates. - - *MUST* remain active in the role and are automatically removed from the - position if they are unresponsive for > 3 months and *MAY* be removed if not - proactively working with other technical leads to fulfill responsibilities. - Removal of a technical lead requires [super-majority] vote amongst tech - leads and chairs. - - *MAY* declare an intention to take sabbatical for no more than 3 months in a - calendar year. Chairs should notify existing chairs of their intent, and - absent at least 2 remaining chairs, *MUST* nominate a temporary replacement - from the existing set of technical leads during this period. - - Technical Leads *SHOULD* represent a diverse set of organizations. This is - predicated on interest in the role from multiple organizations with - qualified candidates. - - *SHOULD* have a record of consistent solid technical judgement and - leadership over a sustained period especially over areas for which they are - the de-facto lead - - Number: 3-7 - - Defined in [sigs.yaml] and [OWNERS] files - -- **Subproject Owners** - - Scoped to a subproject defined in [sigs.yaml] - - Seed subproject owners *MAY* include initial proposal author(s) and/or Tech - Leads - - *MUST* be an escalation point for technical decisions and failing or flaky - tests in the subproject - - *MUST* proactively maintain the subproject health and status or delegate - this responsibility. For actively developed projects, this *SHOULD* include - setting milestone priorities, tracking release bits, and ensure adequate - test coverage. For maintenance mode projects, this *SHOULD* include - maintaining test health and ensuring compatibility with new features. - - *MUST* remain active in the role and are automatically removed from the - position if they are unresponsive for > 3 months. - - *MAY* declare an intention to take sabbatical for no more than 3 months in a - calendar year. Should notify existing owners of their intent, and *MAY* - nominate a temporary replacement from the existing set of owners during this - period. - - *SHOULD* have a record of consistent solid technical judgement over a - sustained period, especially over areas for which they are the owner - - *MAY* be removed if not proactively working with other Subproject Owners to - fulfill responsibilities. - - *MAY* decide to step down at any time and propose a replacement. Use - [lazy-consensus] amongst subproject owners with fallback on majority vote to - accept proposal. This *SHOULD* be supported by a majority of subproject - contributors (those having some role in the subproject). - - *MAY* select additional subproject owners through a [super-majority] vote - amongst subproject owners. This *SHOULD* be supported by a majority of - subproject contributors (through [lazy-consensus] with fallback on voting). - - *SHOULD* work to ensure technical excellence within area - - actively work to reduce complexity of the area - - define general acceptance criteria for work as needed (code, test, - documentation guidelines, etc) - - consider cross-project interactions in technical decisions - - prioritize urgent issues appropriately (e.g. addressing critical bugs, - security vulnerabilities, or test failures) - - Number: 1-7 per subproject (depending on size and scope) - - Defined in [sigs.yaml] [OWNERS] files - -- Members - - *MUST* maintain health of at least one subproject or the health of the SIG - - *MUST* show sustained contributions to at least one subproject or to the SIG - - *SHOULD* hold some documented role or responsibility in the SIG and / or at - least one subproject (e.g. reviewer, approver, etc) - - *MAY* build new functionality for subprojects - - *MAY* participate in decision making for the subprojects they hold roles in - - *SHOULD* include all reviewers and approvers in [OWNERS] files for - subprojects - - *MUST* remain active in the role and may be removed from the position if - they are unresponsive for > 1 year. - - *MAY* be removed if not proactively working with other Subproject Owners to - fulfill responsibilities. - -## Organizational management - -- SIG meets weekly on [zoom] with [agenda in meeting notes] - - *SHOULD* be facilitated by chairs unless delegated to specific Members -- SIG overview and deep-dive sessions organized for Kubecon - - *SHOULD* be organized by chairs unless delegated to specific Members - -- Contributing instructions defined in the SIG CONTRIBUTING.md - -### Project management - -#### Subproject creation - -- Subprojects *MAY* be created by [KEP] proposal and *MUST* be approved by at - least 1 tech lead, and accepted by [lazy-consensus] with fallback on majority - vote of SIG Technical Leads. The result *SHOULD* be supported by the majority - of SIG members. - - KEP *MUST* establish subproject owners - - [sigs.yaml] *MUST* be updated to include subproject information and [OWNERS] - files with subproject owners - - Where subprojects processes differ from the SIG, they must document how - - e.g. if subprojects release separately - they must document how release - and planning is performed - - Subprojects may not be seeded from existing repositories pending CNCF - process definition - -### Technical processes - -Subprojects of the SIG *MUST* use the following processes unless explicitly -following alternatives they have defined. - -- Proposing and making decisions - - Proposals *SHOULD* be sent as [KEP] PRs and published to - [kubernetes-sig-node] as an announcement - - Proposals *MUST* be presented and discussed in at least 1 SIG node meeting - - If the authors are unable to attend, another community member can be found - to champion the proposal. - - Proposals *SHOULD* follow [KEP] decision making process - - For proposed extensions to a subproject, the subproject *MUST* be - identified in the KEP, and approvers *MUST* include subproject owners - -- Test health - - Canonical health of code published to [testgrid] - - Consistently broken tests automatically send an alert to - [kubernetes-sig-node-test-failures] - - SIG members are responsible for responding to broken tests alert. PRs that - break tests should be rolled back if not fixed within 1 business day. - - Test dashboard checked and reviewed at start of each SIG meeting. Owners - assigned for any broken tests and followed up during the next SIG meeting. - -[steering-committee]: https://github.com/kubernetes/community/blob/master/committee-steering/OWNERS -[lazy-consensus]: http://communitymgt.wikia.com/wiki/Lazy_consensus -[super-majority]: https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote -[KEP]: https://github.com/kubernetes/community/blob/master/keps/0000-kep-template.md -[sigs.yaml]: https://github.com/kubernetes/community/blob/master/sigs.yaml -[OWNERS]: https://github.com/kubernetes/community/blob/master/sig-auth/OWNERS -[agenda and meeting notes]: https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit -[zoom]: https://zoom.us/j/4799874685 -[testgrid]: https://k8s-testgrid.appspot.com/sig-node#Summary -[kubernetes-sig-node]: https://groups.google.com/forum/#!forum/kubernetes-sig-node -[kubernetes-sig-node-test-failures]: https://groups.google.com/forum/#!forum/kubernetes-sig-node-test-failures \ No newline at end of file +- network management ([sig-network](../sig-network)) +- persistent storage management ([sig-storage](../sig-storage)) + +## Roles and Organization Management + +This sig adheres to the Roles and Organization Management outlined in [sig-governance] +and opts-in to updates and modifications to [sig-governance]. + +### Additional responsibilities of Chairs + +- Technical leads seeded by legacy SIG chairs from existing subproject owners + +### Additional responsibilities of Tech Leads + +None + +### Deviations from [sig-governance] + +None + +### Subproject Creation + +SIG Technical Leads + + +[validation]: https://github.com/kubernetes/community/blob/master/contributors/devel/cri-validation.md +[testing policy]: https://github.com/kubernetes/community/blob/master/contributors/devel/cri-testing-policy.md +[test grid]: https://k8s-testgrid.appspot.com/sig-node#Summary +[perf dashboard]: http://node-perf-dash.k8s.io/#/builds +[sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md +[readme]: https://github.com/kubernetes/community/tree/master/sig-node +[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md \ No newline at end of file