Community: SIG Cloud Provider Charter

Mon, 01 Jan 0001 00:00:00 +0000

SIG Cloud Provider 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 Cloud Provider’s mission is to simplify, develop, and maintain cloud provider integrations as extensions, or add-ons, to Kubernetes clusters.

In scope

Areas of Focus

Cloud provider specific integrations and extension points that are not already covered by a more specific SIG such as storage or networking.
APIs/interfaces for efficiently provisioning/de-provisioning cloud resources (nodes, routes, load balancers, etc)
Configuration of cluster components to enable cloud provider integrations
Testing and testing frameworks to ensure vendor neutrality across all cloud providers

Code, Binaries and Services

The SIG offers standardization across cloud-provider-* repos that are owned by the SIG. We establish basic structure and tooling expectations to help new contributors to understand the code and how to contribute.

the common interfaces consumed by all cloud providers
the cloud-controller-manager , which acts as the “out-of-tree” cloud provider component for clusters.
core controllers (started by the cloud-controller-manager) that interact with cloud provider resources
all cloud provider repositories under the Kubernetes organization
e2e tests for cloud provider specific functionality
the subproject apiserver-network-proxy , which is an extensible system which controls network traffic from the Kube API Server.
all the subprojects formerly owned by SIG-AWS , SIG-AZURE , SIG-GCP , SIG-IBMCloud , SIG-Openstack , SIG-VMware .
any new subproject that is cloud provider specific, unless there is another SIG already sponsoring it.

Cross-cutting and Externally Facing Processes

This SIG works with SIG Testing & SIG Release to ensure that cloud providers are actively testing & reporting test results to testgrid.
This SIG works with SIG Docs to provide user-facing documentation on configuring Kubernetes clusters with cloud provider integration enabled.
This SIG works with new cloud providers in the ecosystem that want to host their code in the kubernetes-sigs organization and have an interest in contributing back.
A portion of the apiserver-network-proxy code needs to be compiled into the apiserver, which overlaps with SIG API Machinery.
This SIG actively engages with SIGs owning other external components of Kubernetes (CNI, CSI, other networking and storage, apiserver, and similar) to ensure a consistent integration story for users.
This SIG collaborates to create infrastructure-specific endpoints and extensions. This can entail participation in working groups or sponsorship of subprojects.
This SIG participates in cross-SIG working groups, such as the node lifecycle working group.

Out of scope

This SIG does not act as a line of support for Kubernetes users running their clusters on any cloud provider, though many members of the SIG represent cloud providers and are actively engaged with users.
This SIG does not address features/bugs pertaining to cloud providers outside the scope of Kubernetes integrations (e.g. when will instance type X be available on cloud provider Y?)

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

Selecting/prioritizing work to be done for a milestone
Hosting the weekly SIG meeting, ensure that recordings are uploaded in a timely fashion.
Ensuring that the breakout sessions the SIG hosts during the week have chairs.
Organizing SIG sessions at KubeCon events (intro / deep dive sessions).
Creating roadmaps for a given year or release, or reviewing and approving technical implementation plans (e.g. KEPs) in coordination with both SIG Cluster Lifecycle contributors and other SIGs.

Deviations from sig-governance

There should be no more than 1 chair from a single company. This ensures decisions are not being made in favor of a single provider/company.
As SIG cloud provider contains a number of subprojects, the SIG has empowered subproject leads with a number of additional responsibilities, including but not limited to:
- Releases: The subproject owners are responsible for determining the subproject release cadence, producing releases, and communicating releases with SIG Release and any other relevant SIG.
- Backlog grooming: The subproject owners are responsible for ensuring that the issues for the subproject are correctly associated with milestones and that bugs are triaged in a timely manner. PR timeliness: The subproject owners are responsible for ensuring that active pull requests for the subproject are addressed in a timely manner.
- Repository ownership: The subproject owners are given admin permissions to repositories under the subproject. For example, the owners of the Azure subproject are given admin access to the sigs.k8s.io/cloud-provider-azure repository.

Subproject Creation

Federation of Subprojects

Kubernetes Contributors – SIG Cloud Provider