Skip to content

Latest commit

 

History

History
137 lines (120 loc) · 6.43 KB

charter.md

File metadata and controls

137 lines (120 loc) · 6.43 KB
Raw

WG LTS Charter

This charter adheres to the wg-governance guidance, as well as adheres to the general conventions described in the Kubernetes Charter README and the Roles and Organization Management outlined in sig-governance, where applicable to a Working Group.

Scope

The Long Term Support Working Group (WG LTS) is organized with the goal of provide a cross SIG location for focused collection of stakeholder feedback regarding the support stance of Kubernetes project in order to inform proposals for support improvements.

"WG LTS" is simply shorter than "WG To LTS Or Not To LTS" or "WG What Are We Releasing And Why And How Is It Best Integrated, Validate, And Supported", but should NOT be read in that shortness to imply establishing a traditional LTS scheme (multi-year support; upgrade from LTS N to N+1, skipping intermediate versions) is the foregone conclusion of the WG.

In Scope

  • What is a Kubernetes release?
  • What is a supported release? Ie: Stable branches to which critical fixes are backported.
  • Number of community supported branches.
  • Duration of community support per supported branch.
  • Upgrade path considerations.
  • Costs of Kubernetes releases in terms of:
  • Infrastructure
  • People
  • Process: how/where code changes are backported to community supported branches.

Out of Scope

  • The lifecycle of projects outside of the Kubernetes org.
  • Technical and end-user support: The WG will make recommendations around support to those responsible for relevant code and responsible for the release engineering operations and automation, but does not own code itself.
  • Code, test case, automation implementations: this is a working group, no code implementation is the responsibility of this Working Group.

More Details

For even more details on scope and conflicting tradeoffs and implications of different support schemes, please see WG LTS Proposal Presentation, the WG LTS meeting minutes, and WG LTS YouTube Channel.

Stakeholders

Stakeholders in this workgroup span multiple personas and SIGs.

There are developers of Kubernetes internals. Arguably all feature code delivering SIGs are stakeholders here in as much as proposals for changes in support will impact the way the community develops, ships and maintains its code. From the perspective of technical component interoparability across version skews, developers in:

  • SIG API Machinery
  • SIG CLI
  • SIG Node will be particularly impacted if wider version skew support to be attempted.

There is another set of developers of Kubernetes internals who are involved in the integration of Kubernetes with a hosting platform or infrastructure providers and delivering Kubernetes components to run on cluster nodes. This brings in additional dimensions of version skew and does so with more external components and support matrix complexity. These are developers in, for example:

  • SIG Storage (CSI)
  • SIG Network (CNI)
  • SIG Node (CRI)
  • SIG Cloud Provider
    • SIG AWS
    • SIG Azure
    • SIG GCP
    • SIG IBMCloud
    • SIG OpenStack
    • SIG VMware
  • SIG Cluster Lifecycle

There is yet another set of developers of Kubernetes internals who are those involved in meta-topics:

  • SIG Release: production of supported release artifacts
  • SIG Testing: how we can most effectively test Kubernetes
  • Product Security Committee (PSC): security vulnerability handling
  • SIG Architecture: maintains and evolves the design principles of Kubernetes, and provides a consistent body of expertise necessary to ensure architectural consistency over time. Also defines conformance testing.
  • Steering Committee: scope includes deciding how and when official releases of Kubernetes artifacts are made and what they include

Then of course there is also a variety of types of users of Kubernetes:

  • Kubernetes end users
  • Kubernetes cluster operators
  • Kubernetes vendors, distributions, and hosting providers These have their own operational complexities and desires around support duration and supported upgrade version skews.

Deliverables

The specific deliverable is somewhat To-Be-Determined based on initial survey and analysis by the WG.

The initial goal is to enumerate the many and often conflicting desires around support, version skew, and upgrade path, with an eye for possible areas for improvement. Today these topics are covered in a disjoint set of documents across multiple repositories and the official Kubernetes website, so even this enumeration is complicated.

On the one hand the WG's surveys might lead to something larger and strategic like a community agreed and implementable KEP returned to SIG Release to operationalize. This will come from discussion and analysis of the release frequency and support duration relative to adoption and adoption blocking issues.

On the other hand it might lead to more tactical project improvements that result in a culture of and releases characterized by higher quality and stability, such as:

  • Backported patches more rigorously enforced to only contain critical fixes
  • Critical APIs are stable (vN, not vNbetaX)
  • kubernetes/kubernetes repo master branch kept in a releasable state
  • More clear testing signal
  • Higher test coverage
  • Meaningful version-skew, upgrade, and downgrade tests that are immediately fixed, or patches reverted, when broken
  • Reliable API schema upgrades and downgrades
  • Greater supported version skew for kubectl and client-go

Timeline and Disbanding

Working Groups are intended to be time limited endeavors. We expect to survey the state of support in late 2018, especially using KubeCon China and KubeCon North America in November and December 2018 respectively as discussion forums. In early 2019 we hope this coalesces toward concrete proposals, with implementation coming by later 2019.

We will evaluate our mid-year progress and next steps at KubeCon EU 2019 and look to establish a wrap up plan at that point.