|
| 1 | +# SIG Storage Charter |
| 2 | + |
| 3 | +This charter adheres to the conventions described in the [Kubernetes Charter README] and uses |
| 4 | +the Roles and Organization Management outlined in [sig-governance]. |
| 5 | + |
| 6 | +## Scope |
| 7 | + |
| 8 | +SIG Storage is responsible for ensuring that different types of file and block storage |
| 9 | +(whether ephemeral or persistent, local or remote) are available wherever a container is |
| 10 | +scheduled (including provisioning/creating, attaching, mounting, unmounting, detaching, |
| 11 | +and deleting of volumes), storage capacity management (container ephemeral storage |
| 12 | +usage, volume resizing, etc.), influencing scheduling of containers based on storage |
| 13 | +(data gravity, availability, etc.), and generic operations on storage (snapshoting, etc.). |
| 14 | + |
| 15 | +### In scope |
| 16 | + |
| 17 | +Some notable examples of features owned by SIG Storage: |
| 18 | + |
| 19 | +* Persistent Volume Claims and Persistent Volumes |
| 20 | +* Storage Classes and Dynamic Provisioning |
| 21 | +* Kubernetes volume plugins |
| 22 | +* Container Storage Interface (CSI) |
| 23 | +* Secret Volumes, ConfigMap Volumes, DownwardAPI Volumes, EmptyDir Volumes (co-owned with SIG-Node) |
| 24 | + |
| 25 | +#### Code, Binaries and Services |
| 26 | + |
| 27 | +* Kubernetes internal controllers and APIs responsible for exposing file and block storage to Kubernetes workloads. |
| 28 | +* Kubernetes external sidecar containers and binaries required for exposing file and block storage to Kubernetes workloads. |
| 29 | +* Interfaces required for exposing file and block storage to Kubernetes workloads. |
| 30 | +* Unit, Integration, and End-to-End (E2E) Tests validating and preventing regressions in the above. |
| 31 | + |
| 32 | +#### Cross-cutting and Externally Facing Processes |
| 33 | + |
| 34 | +* Defining interface and requirements for connecting third party storage systems to Kubernetes. |
| 35 | + |
| 36 | +### Out of scope |
| 37 | + |
| 38 | +SIG Storage is not responsible for |
| 39 | + |
| 40 | +* Data path of remote storage (GCE PD, AWS EBS, NFS, etc.) |
| 41 | + * How bits are transferred. |
| 42 | + * Where bits are stored. |
| 43 | +* Container writable layer (SIG Node handles that). |
| 44 | +* The majority of storage plugins/drivers (generally owned by storage vendors). |
| 45 | + |
| 46 | +## Roles and Organization Management |
| 47 | + |
| 48 | +SIG Storage adheres to the Roles and Organization Management outlined in [sig-governance] |
| 49 | +and opts-in to updates and modifications to [sig-governance]. |
| 50 | + |
| 51 | +### Deviations from [sig-governance] |
| 52 | + |
| 53 | +SIG Storage does not have separate tech leads: SIG Storage chairs serve as tech leads. |
| 54 | + |
| 55 | +### Subproject Creation |
| 56 | + |
| 57 | +SIG Storage delegates subproject approval to Technical Leads. See [Subproject creation - Option 1]. |
| 58 | + |
| 59 | +[sig-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md |
| 60 | +[Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md |
| 61 | +[Subproject creation - Option 1]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md#subproject-creation |
0 commit comments