kubernetes / enhancements Goto Github PK

View Code? Open in Web Editor NEW

3.3K 381.0 1.4K 32.7 MB

Enhancements tracking repo for Kubernetes

License: Apache License 2.0

Shell 18.87% Go 72.18% Makefile 4.80% Python 2.63% Mermaid 1.52%

kubernetes kubernetes-releases k8s-sig-architecture enhancements

enhancements's Introduction

Enhancement Tracking and Backlog

Is My Thing an Enhancement?
When to Create a New Enhancement Issue
Why Are Enhancements Tracked
When to Comment on an Enhancement Issue
Enhancements Tracking Board
Enhancements Tracking Spreadsheet
Current Release Cycle
Exceptions to Enhancement Milestone Dates
Labels
Glossary

Enhancement tracking repo for Kubernetes releases. Owned by SIG Architecture.

This repo contains issues and KEPs. These issues are umbrellas for new enhancements to be added to Kubernetes. An enhancement usually takes multiple releases to complete. And an enhancement can be tracked as backlog items before work begins. An enhancement may be filed once there is consensus in at least one Kubernetes SIG.

Is My Thing an Enhancement?

We are trying to figure out the exact shape of an enhancement. Until then, here are a few rough heuristics.

An enhancement is anything that:

a blog post would be written about after its release (ex. minikube, StatefulSets, rkt container runtime)
requires multiple parties/SIGs/owners participating to complete (ex. GPU scheduling [API, Core, & Node], StatefulSets [Storage & API])
will be graduating from one stage to another (ex. alpha to beta, beta to GA)
needs significant effort or changes Kubernetes in a significant way (ex. something that would take 10 person-weeks to implement, introduce or redesign a system component, or introduces API changes)
impacts the UX or operation of Kubernetes substantially such that engineers using Kubernetes will need retraining
users will notice and come to rely on

It is unlikely an enhancement if it is:

implemented using a CustomResourceDefinition
fixing a flaky test
refactoring code
performance improvements, which are only visible to users as faster API operations, or faster control loops
adding error messages or events

If you are not sure, ask someone in the SIG where you initially circulated the idea. If they aren't sure, jump into #enhancements on Slack or ping someone listed in OWNERS.

When to Create a New Enhancement Issue

Create an issue in this repository once you:

have circulated your idea to see if there is interest
- through Community Meetings, SIG meetings, SIG mailing lists, or an issue in github.com/kubernetes/kubernetes
(optionally) have done a prototype in your own fork
have identified people who agree to work on the enhancement
- many enhancements will take several releases to progress through Alpha, Beta, and Stable stages
- you and your team should be prepared to work on the approx. 9mo - 1 year that it takes to progress to Stable status
are ready to be the project manager for the enhancement

Why Are Enhancements Tracked

Once users adopt an enhancement, they expect to use it for an extended period of time. Therefore, we hold new enhancements to a high standard of conceptual integrity and require consistency with other parts of the system, thorough testing, and complete documentation. As the project grows, no single person can track whether all those requirements are met.

The development of an enhancement often spans three stages: Alpha, Beta, and Stable. Enhancement Tracking Issues provide a checklist that allows for different approvers for different aspects, and ensures that nothing is forgotten across the development lifetime of an enhancement.

When to Comment on an Enhancement Issue

Please comment on the enhancement issue to:

request a review or clarification on the process
update status of the enhancement effort
link to relevant issues in other repos

Please do not comment on the enhancement issue to:

discuss a detail of the design, code or docs. Use a linked-to-issue or PR for that

Enhancements Tracking Board

As of the 1.26 release, enhancements from this repo are visualized in the Enhancements Tracking Boards.

Links:

Enhancements Tracking Spreadsheet

Prior to the 1.26 release, enhancements from this repo were visualized using Enhancements Tracking Spreadsheets.

Please refer to the Enhancements Tracking Spreadsheet Archive for links to these sheets.

Procedure: TBA

Current Release Cycle

Dates and further information for the 1.28 Release

Exceptions to Enhancement Milestone Dates

The Exceptions Process is handled by the Release Team, please see their documentation for further details.

Labels

Label Name	Purpose	How to use this label	Who should use this label
`sig/foo`	Denotes the SIG(s) which owns this enhancement—e.g., `SIG Foo`	Set the label using the comment `/sig foo` (on a separate line)	Anyone
`kind/feature`	Denotes that the issue should be tracked as an enhancement (all enhancement issues should be marked with this label)	Set the label using the comment `/kind feature` (on a separate line)	Anyone
`stage/{alpha,beta,stable}`	Denotes the stage of an issue in the features process	Set the label using the comment `/stage alpha` (on a separate line)	Anyone

Glossary

Please refer to the Glossary for the definition of any terminology and acronyms used in the Enhancements subproject.

enhancements's People

Contributors

Stargazers

Watchers

Forkers

pwittrock verb e-llp philips ramitsurana mdshuai timstclair girishkalele aronchick pigmej goltermann grodrigues3 zachaller bowei pipejakob calind nickinchina aresall1990 kri5 mdelio spiffxp davidopp enisoc lvjiangzhao luxas madhusudancs marif2 mwielgus yujuhong smarterclayton mrhohn giltayar harmonycloud xulike666 dongziming ckarlsen84 ethernetdan fate-grand-order alfred-huangjian flowerpp lukemarsden jbeda maxwell92 liggitt mikedanese justinsb tksm craigbox piosz ejc3 gnufied pabloguerrero dockernuts volkvolkovblr jbw976 ericln shrutir25 marun chenopis mtanino calebamiles aveshagarwal nefuddos mingderwang emaildanwilson evie404 rohitagarwal003 feiskyer random-liu superbrothers mtaufen sbueringer strin nashasha1 tengqm jdumars crimsonfaith91 mbssaiakhil jcbsmpsn sjenning kow3ns chris-milsted bsalamat directxman12 alex8866 connordoyle janetkuo ericchiang yguo0905 caoshufeng soltysh bradamant3 zacharysarah ttindell2 wackxu yuxijin-tobeyjin caseydavenport radhikapc islinwb roberthbailey

enhancements's Issues

Allow Tags on Containers

Description

This feature adds a way for users to control metadata tags on their containers. Each of the various container runtimes has a way to put some sort of user tag on containers. Giving users control over this is useful for scenarios in which the user wants to integrate Kubernetes with other platforms and facilities.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Simplify HA Setup for Master

Description

Simplify setup for HA Master. Description in kubernetes/kubernetes#29649

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Role-based access control (RBAC)

Feature Description

One-line feature description (can be used as a release note): Role-based access control
Primary contact (assignee): @ericchiang @deads2k @liggitt
Responsible SIGs: sig-auth
Design proposal link (community repo):
Reviewer(s): @deads2k @ericchiang
Approver (likely from SIG/area to which feature belongs): @erictune @smarterclayton
Feature target (which target equals to which milestone):
- Alpha release target - 1.3
- Beta release target - 1.6
- Stable release target - 1.8

kubernetes/kubernetes#25634
kubernetes/kubernetes#26753
kubernetes/website#643

Federated Secrets

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Kubectl login subcommand

Description

Add a subcommand to kubectl which can update kubeconfig auth providers configs (kubernetes/kubernetes#23066) and trigger login events. The initial implementation will add support for the OpenID Connect auth provider and a basic auth challenge.

Prior POC and discussion in kubernetes/kubernetes#25758

cc @kubernetes/sig-auth

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Dramatically Simplify Kubernetes Cluster Creation (kubeadm umbrella issue).

Description

Creating a new Kubernetes cluster is too hard. We need to simplify the number and types of actions to get a production cluster up and running.

Note that this is different from bringing up a development cluster (single node ala monokube or minikube) or automation around cluster creation (https://github.com/kubernetes/community/wiki/Roadmap:-Cluster-Deployment).

If we do this right, the number of manual steps to get a cluster running should be minimal. This will have the added benefit of making other deployment scenarios (dev cluster, cluster automation) simpler and smaller.

As part of this, we should make simplifying assumptions and have opinionated defaults. An example would be embedding etcd and picking an easy to use network technology. Certificates and trust should be established automatically.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Federation: Generalized Cluster Selection and Weighting

Feature Description

One-line feature description (can be used as a release note):
Primary contact (assignee): @marun
Responsible SIGs: @kubernetes/sig-federation-feature-requests
Design proposal link (community repo):
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
Approver (likely from SIG/area to which feature belongs):
Feature target (which target equals to which milestone):
- Alpha release target (x.y)
- Beta release target (x.y)
- Stable release target (x.y)

# Description
Many of the existing (v1.4) federated API objects are by default scheduled across all underlying clusters (e.g. federated services, namespaces, secrets, ingress...). Federated replicasets support a set of alpha annotations by which the user can influence replica placement. This alpha concept is extended to a fully supported API for scheduling entities across multiple clusters and cloud providers.

The beginnings of a design proposal are here:

https://docs.google.com/document/d/1dbKS6banuv44eEUm4YLNvEI0lDa1dpI-Z1E4MWeEyxQ/edit?ts=58f4e60e

Progress Tracker

Before Alpha

Write and maintain draft quality doc https://docs.google.com/document/d/1dbKS6banuv44eEUm4YLNvEI0lDa1dpI-Z1E4MWeEyxQ/edit?ts=58f4e60e

During development keep a doc up-to-date about the desired experience of the feature and how someone can try the feature in its current state. Think of it as the README of your new feature and a skeleton for the docs to be written before the Kubernetes release. Paste link to Google Doc: DOC-LINK

Design Approval

Design Proposal. This goes under docs/proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here: PROPOSAL-NUMBER

Initial API review (if API). Maybe same PR as design doc. PR-NUMBER

Any code that changes an API (/pkg/apis/...)

cc @kubernetes/api

Identify shepherd (your SIG lead and/or [email protected] will be able to help you). My Shepherd is: [email protected] (and/or GH Handle)

A shepherd is an individual who will help acquaint you with the process of getting your feature into the repo, identify reviewers and provide feedback on the feature. They are not (necessarily) the code reviewer of the feature, or tech lead for the area.

The shepherd is not responsible for showing up to Kubernetes-PM meetings and/or communicating if the feature is on-track to make the release goals. That is still your responsibility.

Identify secondary/backup contact point. My Secondary Contact Point is: [email protected] (and/or GH Handle)

Write (code + tests + docs) then get them merged. ALL-PR-NUMBERS

Code needs to be disabled by default. Verified by code OWNERS

Minimal testing

Minimal docs

cc @kubernetes/docs on docs PR

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io

Update release notes

Before Beta

Testing is sufficient for beta

User docs with tutorials

Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io

cc @kubernetes/docs on docs PR

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Thorough API review

cc @kubernetes/api

Before Stable

docs/proposals/foo.md moved to docs/design/foo.md

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Soak, load testing

detailed user docs and examples

cc @kubernetes/docs

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.

As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.

When you are done with the code, apply the "code-complete" label.

When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.

User docs go into http://github.com/kubernetes/kubernetes.github.io.

When the feature has user docs, please add a comment mentioning @kubernetes/docs.

When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Container Image Policy

Description

Organizations wish to avoid running "unapproved" images.

The exact nature of "approval" is beyond the scope of Kubernetes, but may include reasons like:

only run images that are scanned to confirm they do no contain vulnerabilities
only run images that use a "required" base image
only run images that contain binaries which were built from peer reviewed, checked-in source by a trusted compiler toolchain.
etc...

Progress Tracker

FEATURE_STATUS: Proposal review

Configurable Dynamic Provisioning aka StorageClass

Description

The current dynamic provisioning feature supports only a single provisioner per cluster. This feature will allow multiple provisioners to be configured in a single cluster.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Private Federated Services

Description

Federated services that are not exposed on public IP's or public DNS names.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Define NodeSpec

Description

As a user, I want to add my own nodes to Kubernetes, and make sure they meet the minimum requirements for running as a Kubernetes node so that I can use pre-approved images, and speed adding new compute. cc @yujuhong @dchen1107

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Addon management layer

Feature Description

One-line feature description (can be used as a release note): Support for system addon management
Primary contact (assignee): @justinsb
Responsible SIGs: @kubernetes/sig-cluster-lifecycle-feature-requests
Design proposal link (community repo):
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
Approver (likely from SIG/area to which feature belongs):
Feature target (which target equals to which milestone):
- Alpha release target (x.y) 1.8
- Beta release target (x.y) 1.9
- Stable release target (x.y) 1.10

# Description
Currently add-on management is baked in kube-up.sh and is subject to various kinds of issues. Current implementation lacks transparency, clear specification and any separation from other layers, among other more technical downsides. This part of the effort towards #11, and is a fairly easy one to tackle.

As discussed in kubernetes-retired/kubernetes-anywhere#126, it looks like a low-hanging fruit, and existing projects can be easily used to pave the way. More specifically, the assumption is that Helm should work pretty well for this, and only a thin layer of automation would be required to make it seamless.

Progress Tracker

Before Alpha

Design Approval

Design Proposal. This goes under docs/proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here:

kubernetes/kubernetes#29551

Initial API review (if API). Maybe same PR as design doc. PR-NUMBER

Any code that changes an API (/pkg/apis/...)

cc @kubernetes/api

Write (code + tests + docs) then get them merged. ALL-PR-NUMBERS

Code needs to be disabled by default. Verified by code OWNERS

Minimal testing

Minimal docs

cc @kubernetes/docs on docs PR

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io

Update release notes

Before Beta

Testing is sufficient for beta

User docs with tutorials

Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io

cc @kubernetes/docs on docs PR

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Thorough API review

cc @kubernetes/api

Before Stable

docs/proposals/foo.md moved to docs/design/foo.md

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Soak, load testing

detailed user docs and examples

cc @kubernetes/docs

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.

As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.

When you are done with the code, apply the "code-complete" label.

When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.

User docs go into http://github.com/kubernetes/kubernetes.github.io.

When the feature has user docs, please add a comment mentioning @kubernetes/docs.

When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Add a simple template API object that assists with config parameterization

Description

Simple config parameterization is an important tool for extending the utility of example config. This feature will add an API object that represents a set of standard parameters and a list of objects with replacement syntax, a minimal set of CLI commands that transform templates + parameters into a list of API objects, and an API endpoint that allow templates to be stored.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Workload spreading across failure domains (fix pod anti-affinity performance problem)

Description

As a user, I want to be able to spread workloads to multiple clusters spread across multiple failure domains to improve my application uptime.

(Note: This is just one use case for pod affinity/anti-affinity.)

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

System Correctness: Single Source for Default Values

Description

Developers have a single place where defaults should be coded, and kubectl doesn't need to roundtrip json before sending it to the apiserver

kubectl doesn't apply defaults or overwrite apiserver - the apiserver is the single place where defaults are intelligently created. cc @lavalamp

kubernetes/kubernetes#3955

Access Review APIs

Description

The API server should provide endpoints to allow access control checks and subject access checks without direct knowledge of the backing authorization engine. This allows delegation of authorization.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

API Audit Logging

The Kubernetes apiserver can generate audit logs for all requests, and export to a pluggable backend.
Primary contact (assignee): Tim Allclair @tallclair
Responsible SIGs: sig-auth
Design proposal link (community repo): https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auditing.md
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @sttts @soltysh @x13n
Approver (likely from SIG/area to which feature belongs): @sttts @tallclair
Feature target (which target equals to which milestone):
- Alpha release target (1.7)
- Beta release target (1.8) - kubernetes/kubernetes#48561
- Stable release target (1.12) - kubernetes/kubernetes#65891
Docs: https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/tasks/debug-application-cluster/audit.md

GCP Cloud Provider: Source IP preservation for Virtual IPs

Feature Description

One-line feature description (can be used as a release note): Source IP Preservation - change Cloud load-balancer strategy to health-checks and respond to health check only on nodes that host pods for the service.
Primary contact (assignee): @MrHohn
Responsible SIGs: sig-network
Design proposal link (community repo): https://github.com/kubernetes/community/blob/master/contributors/design-proposals/external-lb-source-ip-preservation.md
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @thockin @freehan @bprashanth
Approver (likely from SIG/area to which feature belongs): @thockin
Feature target (which target equals to which milestone):
- Alpha release target (1.4)
- Beta release target (1.5)
- Stable release target (1.7)

Automate Docker Validation Process

EDITED by @dchen1107 on Sept 23, 2016

Description

Currently, Docker (https://www.docker.com/) is the default container runtime used by Kubernetes. Kubernetes release quality is significantly affected by Docker release quality.

The container technology evolves very rapidly, and so does Docker. Kubernetes can’t stick with a specific Docker version because

Customers might ask for new features in new Docker release.
Each Docker release solves some known issues and enhances the overall reliability and performance.

Docker releases per month, and before each release there are also several pre-releases. To ensure Kubernetes compatible with new Docker release, every quarter we had to invest at least 2-week engineer time to manually validate Docker release quality. For example, for 1.3 Kubernetes release, Kubernetes engineer manually validated

Docker 1.9: kubernetes/kubernetes#16110
Docker 1.10: kubernetes/kubernetes#19720
Docker 1.11: kubernetes/kubernetes#23397

but we still couldn't cover all Docker (pre)release.

Thus, we developed the automated docker validation framework. It is a framework automatically validates newest Docker (pre)release against Kubernetes HEAD everyday, the validation includes functionality validation and performance validation.

Progress Tracker

Finish Federated Services

Description

Finish the federated services that have been completed in 1.3. This description is woefully incomplete and will be fleshed out/replaced by @quinton-hoole.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Vertical Scaling of Pods

Description

Make it possible to vary the resource limits on a pod over its lifetime. In particular, this is valuable for pets (i.e., pods that are very costly to destroy and re-create).

This was discussed in the Node SIG meeting of 12 July 2016, where it was noted that this is a big cross-cutting issue and that @ncdc might be an appropriate owner.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

[Deprecated] Pod Security Policy

Feature Description

Define policy objects that limit what security-related features pods and containers can use
Primary contact (assignee): @tallclair
Responsible SIGs: @kubernetes/sig-auth-feature-requests @kubernetes/sig-node-feature-requests
Design proposal link (community repo): https://github.com/kubernetes/community/blob/master/contributors/design-proposals/auth/pod-security-policy.md
Link to e2e and/or unit tests: https://github.com/kubernetes/kubernetes/blob/master/test/e2e/auth/pod_security_policy.go
Reviewer(s) - (for LGTM): @liggitt @tallclair
Approver: @liggitt @tallclair
Feature target (which target equals to which milestone):
- Beta release target (extensions/v1beta1) - 1.8
- Beta release target (policy/v1beta1) - 1.10
- Stable release target - TBD

Related issues

kubernetes/kubernetes#43214 - Move out of extensions/v1beta1 API group:
- 1.10
  - additionally allow authorizing via use verb in policy API group (will need to allow via either group for some time period)
  - update e2e tests (test both for some time period)
- 1.11
  - move internal types to policy package (cleanup)
  - move registry to policy package (cleanup)
  - update addon manifests to use policy/v1beta1, grant permissions in policy API group
  - switch admission plugin to use policy group informer
  - switch preferred storage version to policy group
kubernetes/kubernetes#56174
kubernetes/kubernetes#55435
kubernetes/kubernetes#56173

rkt container engine support

Description

There is ongoing work for Kubernetes' support of rkt as a production-ready, generally usable container runtime option. This project is sometimes called rktnetes. 🚀

There has already been significant work to implement this feature, and as of v1.3 it's already a supported option. However, it does not yet have full feature parity with the default Docker runtime, and I would be wary of calling it "production ready".

In order to have a sane scope for this feature, I'd like for it to track the rkt container runtime having full support for all Kubernetes features, support in Kubernetes deployment, well documented, and a great production choice.

Progress Tracker

FEATURE_STATUS: IN_DEVELOPMENT (I'm not sure the right status; this has had an initial release suitable for use; development is being done to improve the integration and address known issues / caveats).

cc @kubernetes/sig-node

Short meta-note: This feature might or might not actually fit here since it's something that is and has been in progress for quite a while. Many of the bullet points don't work well for it because of its circumstances, and I'm hopeful that it can help refine this process a bit; I've taken some liberties with formatting.

Handle out-of-disk and refactor intelligent disk management

Description

Building on the disk accounting in 1.3, handle out-of-disk and refactor intelligent disk management. Proposal will be fleshed out by @dchen1107 or assignee.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

ConfigMaps can consume pod facts

Description

The idea is to add templated variables to ConfigMap values, so each time a ConfigMap is applied to a pod - it can transform the value into something specific to a pod. Right now the best example is pod IP address.

Example

We assume that there are two possible variables that can be used to consume pod facts: pod.IP and pod.name, which evaluate to pod.Status.podIP and pod.Name.

Let's consider following ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  service.ip: $(pod.IP)
  other.value: trololo
  service.name: $(pod.name)

Then we have a pod with a service that needs to put the IP of the pod in the config file /etc/config/service.ip.

Pod manifest can look like that:

apiVersion: v1
kind: Pod
metadata:
  name: pod-facts-consumer
spec:
  containers:
    - name: test-container
      image: gcr.io/google_containers/busybox
      command: [ "/bin/sh", "cat", "/etc/config/service.ip" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
  restartPolicy: Never

When we create above ConfigMap and run the pod, we expect the test-container output to be an IP address that was assigned to the Pod.

The proof of concept implementation is demoed here: https://asciinema.org/a/e90cs3ymgtatdexk6rmjuet92

It uses the code from this fork/branch: https://github.com/nebril/kubernetes/tree/pod-facts-in-configmaps.

This feature will allow applications that need pod facts to be configured properly using just ConfigMaps. An example of such application can be Galera, which needs local IP addresses in my.conf file.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Federated ReplicaSet

Feature Description

One-line feature description (can be used as a release note): Support ReplicaSets in Federation
Primary contact (assignee): @perotinus
Responsible SIGs: @kubernetes/sig-federation-feature-requests
Design proposal link (community repo): https://github.com/kubernetes/community/blob/09ef55a496f8928573f7f4d2a8a38d0601737ddb/contributors/design-proposals/federated-replicasets.md
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @marun
Approver (likely from SIG/area to which feature belongs): @madhusudancs
Feature target (which target equals to which milestone):
- Alpha release target (x.y): 1.5
- Beta release target (x.y): 1.7

Federation per-user cluster authentication, authorization and audit logging

Feature Description

One-line feature description (can be used as a release note):
Primary contact (assignee): @nikhiljindal
Responsible SIGs: @kubernetes/sig-federation-feature-requests
Design proposal link (community repo):
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred:
Approver (likely from SIG/area to which feature belongs):
Feature target (which target equals to which milestone):
- Alpha release target (x.y)
- Beta release target (x.y)
- Stable release target (x.y)

# Description
In v1.3, v1.4 of Cluster Federation, the Kubernetes v1.3 style authentication model is used. A single set of credentials per cluster is used by the federation control plane to access underlying clusters on behalf of all users of the federation. The underlying clusters have no idea who the federation user on behalf of whom the federation control plane is acting is.

In this enhancement, each federation user will be individually authenticated, authorized and tracked in underlying clusters.

Progress Tracker

Before Alpha

Write and maintain draft quality doc

During development keep a doc up-to-date about the desired experience of the feature and how someone can try the feature in its current state. Think of it as the README of your new feature and a skeleton for the docs to be written before the Kubernetes release. Paste link to Google Doc: DOC-LINK

Design Approval

Design Proposal. This goes under docs/proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here: PROPOSAL-NUMBER

Initial API review (if API). Maybe same PR as design doc. PR-NUMBER

Any code that changes an API (/pkg/apis/...)

cc @kubernetes/api

Identify shepherd (your SIG lead and/or [email protected] will be able to help you). My Shepherd is: [email protected] (and/or GH Handle)

A shepherd is an individual who will help acquaint you with the process of getting your feature into the repo, identify reviewers and provide feedback on the feature. They are not (necessarily) the code reviewer of the feature, or tech lead for the area.

The shepherd is not responsible for showing up to Kubernetes-PM meetings and/or communicating if the feature is on-track to make the release goals. That is still your responsibility.

Identify secondary/backup contact point. My Secondary Contact Point is: [email protected] (and/or GH Handle)

Write (code + tests + docs) then get them merged. ALL-PR-NUMBERS

Code needs to be disabled by default. Verified by code OWNERS

Minimal testing

Minimal docs

cc @kubernetes/docs on docs PR

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io

Update release notes

Before Beta

Testing is sufficient for beta

User docs with tutorials

Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io

cc @kubernetes/docs on docs PR

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Thorough API review

cc @kubernetes/api

Before Stable

docs/proposals/foo.md moved to docs/design/foo.md

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Soak, load testing

detailed user docs and examples

cc @kubernetes/docs

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.

As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.

When you are done with the code, apply the "code-complete" label.

When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.

User docs go into http://github.com/kubernetes/kubernetes.github.io.

When the feature has user docs, please add a comment mentioning @kubernetes/docs.

When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Provide Opt-in Self-Reporting Pod

Description

The Kubernetes project would love to collect information about how customers are using their clusters, to help us prioritize work. The initial version of this feature would be downloaded (separate from installation) and would report on a regular basis:

A UUID for the cluster
How old the cluster is
How many nodes are running on the cluster and what the profile of each node is
How many pods, RCs, services, deployments and jobs are on the cluster

All data would be stripped of any PII before submission, and shared with the CNCF.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

AppController - statefull app deployments

Description

AppController will allow to work with statefull applications that involve many components (openstack for example) more easy and more native. AppController will understand dependencies between kubernetes objects and therefore it will create them in correct order.

kubernetes/kubernetes issue: kubernetes/kubernetes#29453

cc @kubernetes/sig-openstack @kubernetes/sig-apps

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Forgiveness

Description

taints/tolerations is a building block for this
what it is: "instead of the usual five minutes, wait to evict this pod until the node has been not-ready for N minutes" (where N is selected in the pod); this is useful for stateful apps where it's painful to rebuild state on a new node
we'll have a simple version of this in 1.4; see here: kubernetes/kubernetes#1574 (comment)

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Enable non-go clients: Move to OpenAPI(Swagger 2.0)

Description

Third party orchestrators can use a clean, swagger 2.0 based interface to interact with K8s, improving the ability to build k8s clients, and letting users use tools they are familiar with, and read up to date documentation. (includes + Swagger bug fixes). This description will be fleshed out by @lavalamp.

Progress Tracker

Basic Swagger 2.0 discovery documents are served by 1.4 kube-apiserver.

There are many planned improvements but we will treat them as bug fixes.

(lavalamp deleted all of the checkboxes that used to be here because they don't make any sense for this feature.)

CronJobs (previously ScheduledJobs)

Enhancement Description

Support Api Object Templates

Thanks for wanting to add a feature to Kubernetes! You will be responsible for guiding
your feature through completion, and asking the right people for approvals.

Large features typically go through three stages: Alpha, Beta, and Stable
Each stage requires various approvals from various teams.

You can use the checkboxes below to
track your progress. You can delete the text above once you have read it. Please keep the checklist.

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Kubelet TLS Bootstrap

Feature Description

One-line feature description (can be used as a release note): kubelet generates a private key and a CSR for submission to a cluster-level certificate signing process.
Primary contact (assignee): @mikedanese
Responsible SIGs: sig-auth
Design proposal link (community repo): https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/kubelet-tls-bootstrap.md
Link to e2e and/or unit tests:
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @liggitt
Approver (likely from SIG/area to which feature belongs): @liggitt
Feature target (which target equals to which milestone):
- Alpha release target (1.4)
- Beta release target (1.6)
- Stable release target (1.12)

Support multiple image types, e.g. OCI

Description

Currently, a Kubernetes Pod's containers are assumed to be Docker images (and to use Docker's discovery).

However, with the progress of the OCI Image Spec, the inclusion of the rkt runtime (which supports docker, OCI, and ACI images), it's clear that now is a good time to consider making it possible to run additional formats.

Existing discussion of this feature have already shown demand and intent to address it eventually, just not urgency.

Ref: An old proposal, a user's request, and a bit more discussion.

This issue could also relate to generalizing image transport (ref kubernetes/kubernetes#15484), but does not necessarily have to.

Progress Tracker

FEATURE_STATUS: PENDING

Note: This feature does not currently have a shepherd and it is likely it will not make the v1.4 milestone. I think tentatively marking it v1.5 and trying to get a shepherd and initial proposal a little before the v1.4 release would be a good thing to shoot for.

Ingress for Multi-Zone Clusters

Description

Provide ingress for multi-zone clusters. This description will be fleshed out by @quinton-hoole.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

AppArmor support

Description

Add AppArmor support to Kubernetes. Initial support should include the ability to specify an AppArmor profile for a container or pod in the API, and have that profile applied by the container runtime.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: BETA

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Add sysctl support

Description

This feature aims at extending the current pod specification with support
for namespaced kernel parameters (sysctls) set for each pod.

Scope of work planned for v1.11

graduate to beta

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Allow namespace rather than kubelet to supply the added DNS client config

Description

The use case for this new feature is a Kubernetes operator who is providing a multi-tenant service based on namespaces. Each namespace belongs to one tenant. One tenant should not have a view of the whole cluster; rather the tenant's view should be constricted properly.

There are a few facets to this problem. One of them is the DNS client configuration applied in the tenant's pods. The k8s API has an optional dnsPolicy field in a PodSpec, and that field's value can be either ClusterFirst or Default; the default behavior is that of ClusterFirst. The Default setting means that the pod uses its host's DNS client configuration. The ClusterFirst setting means that the pod's DNS client configuration ignores the host's DNS client configuration and gives the pod only settings based on the kubelet arguments. The kubelet's --cluster-dns parameter, if supplied, is prepended to the DNS server list. The domain search list is prepended by the kubelet's --cluster-domain parameter if there is one, and then svc.cluster.local cluster.local (where the cluster.local part can be varied by another kubelet parameter) unconditionally.

The idea in this proposal is to allow a namespace to override the behavior of the ClusterFirst setting to make it mean that the stuff prepended comes from a new namespace field rather than kubelet parameters. We introduce into NamespaceSpec an optional field dnsClientConfig of a new type DNSClientConfig. A DNSClientConfig holds a list of DNS server addresses and a list of strings (search domains). If the dnsClientConfig is present in a namespace then for every pod in that namespace the ClusterFirst behavior is to derive the pod's DNS client config by prepending the contents of the namespace's DNSClientConfig (rather than the settings derived from the kubelet parameters) to the config from the host.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Support services that reference an external service

Description

Services should be able to reference an external DNS address instead of only pods, which will allow application authors to reference services that exist off platform, on other clusters, or locally.

Owner @rata

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Inter-pod affinity/anti-affinity

Design Doc: https://github.com/kubernetes/kubernetes/blob/master/docs/design/podaffinity.md

e.g. "put these pods in zone us-central1-a"
predicate and priority function are done, it was alpha in 1.2, no change in 1.3
remaining work (low-priority since nobody has been asking for it) is to implement the "RequiredDuringExecution" option which means evict a pod if node labels change, or pod's affinity/anti-affinity request changes, such that the pod's affinity/anti-affinity is no longer satisfied
In theory we could move it to Beta in 1.4 but I think we should leave it as alpha for two reasons: (1) get more people using it so we can get feedback, (2) it shares the same annotation (scheduler.alpha.kubernetes.io/affinity) with inter-pod affinity/anti-affinity (see below), and we definitely need to keep that one in alpha in 1.4

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

kubelet evicts resources when observing disk pressure

Description

As a cluster operator, I want the kubelet to monitor local disk usage and respond accordingly to maintain node stability. If the kubelet observes available disk and/or inodes (rootfs or imagefs) are under pressure, the kubelet should pro-actively reclaim related resource to maintain node stability by deleting images, logs, and evicting pods.

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Federated Namespaces

Description

Add description here

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Prioritized scheduling of critical cluster addon pods

Description

Kubernetes has "cluster addon pods" that provide system services but do not run on the master node. Some of them are critical to have fully functional cluster: Heapster, DNS, UI. Users can break their cluster by evicting a critical addon (either manually or as a side effect of an other operation like upgrade) which possibly can become pending (for example when the cluster is highly utilized). To avoid such situation we introduce a rescheduler component that runs on the master and guarantees that critical addons are scheduled assuming the cluster is big enough. It does this by watching for pending critical pods and evicting other pods to make room for the pending one(s).

Design Proposal: kubernetes/kubernetes#29195

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Federated Secrets

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Performance and scale improvements to core infrastructure and clients to hit scale goals

Description

Continue to refine the performance of the API server, controllers, and client infrastructure to achieve our scale goals (~5k nodes and 300k pods) on a single cluster. This involves continuous testing at scale and refinement of our core systems for efficiency, as well as scaling testing from many large deployments.

By the 1.4 release, we hope to identify major scale blockers between the current certified numbers and our target numbers and get much closer.

Progress Tracker

FEATURE_STATUS: ONGOING

Design

Summarization of ongoing work under kubernetes/kubernetes#27667

Coding

PRs are tracked under https://github.com/kubernetes/kubernetes/issues?utf8=✓&q=label%3Aarea%2Fperformance+label%3A%22team%2FCSI-API+Machinery+SIG%22+
Coding work is prioritized by the sig-scale and sig-api-machinery groups.
PRs trying to make v1.4

Docs

None specifically required at this point.

Federation Events

Description

Add description here

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

etcd v3 as storage backend for APIServer

Description

This feature was merged into v1.3 and is an alpha feature behind a flag. Creating a feature for tracking through the rest of the process.

etcd v3 is a new API supported by etcd v3.0.0+. There are a number advantages of this new API but there are a changes that need to happen both externally, like turning etcd v3 on by default and migration docs, and internally, like testing and continued storage improvements, to fully take advantage of etcd v3.

Why is this a feature? It slightly changes the operation of Kubernetes clusters and impacts SIG Scalabilities and SIG API Machinery work. This is already an alpha feature today that makes etcd v3 a non-default backend but there is work that remains to move from an alpha feature to a well tested complete feature.

Progress Tracker

FEATURE_STATUS: Stable

Redefine the Container Runtime Interface

Description

We should separate image management, resource / cgroup management, logging management from today's runtime interface. After this effort, we effectively make today's runtime interface as pod / container lifecycle management interface. cc @yujuhong @dchen1107

Proposal here: kubernetes/kubernetes#25899

Progress Tracker

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.
When you are done with the code, apply the "code-complete" label.
When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.
User docs go into http://github.com/kubernetes/kubernetes.github.io.
When the feature has user docs, please add a comment mentioning @kubernetes/docs.
When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

Federated read access to cluster API objects

Feature Description

One-line feature description (can be used as a release note): Federated read access to cluster API objects
Primary contact (assignee): [email protected] aka [email protected]
Responsible SIGs: @kubernetes/sig-federation-feature-requests
Design proposal link (community repo): https://docs.google.com/document/d/1H2BkqSKvoCSifi7c8D2gASSJo20ocIEYDMSfNfcylBc/edit#
Reviewer(s) - @quinton-hoole @nikhiljindal
Approver (likely from SIG/area to which feature belongs): @quinton-hoole
Feature target (which target equals to which milestone):
- Alpha release target (1.8)
- Beta release target (1.9)
- Stable release target (1.10)

# Description
Accessing Kubernetes resources from federation apiserver feature enables users to be able to get all or a subset of all their resources from all their Kubernetes clusters under federation by talking to federation Apiserver. Note that users will be able to get all resources from underlying clusters, not just the ones which have a corresponding federation object.

The design doc is in progress will be uploaded soon

Progress Tracker

Alpha

Write and maintain draft quality doc

During development keep a doc up-to-date about the desired experience of the feature and how someone can try the feature in its current state. Think of it as the README of your new feature and a skeleton for the docs to be written before the Kubernetes release. Paste link to Google Doc: DOC-LINK

Design Approval

Design Proposal. This goes under design-proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here: PROPOSAL-NUMBER

Decide which repo this feature's code will be checked into. Not everything needs to land in the core kubernetes repo. REPO-NAME

Initial API review (if API). Maybe same PR as design doc. PR-NUMBER

Any code that changes an API (/pkg/apis/...)

cc @kubernetes/api

Identify shepherd (your SIG lead and/or [email protected] will be able to help you). My Shepherd is: [email protected] (and/or GH Handle)

A shepherd is an individual who will help acquaint you with the process of getting your feature into the repo, identify reviewers and provide feedback on the feature. They are not (necessarily) the code reviewer of the feature, or tech lead for the area.

The shepherd is not responsible for showing up to Kubernetes-PM meetings and/or communicating if the feature is on-track to make the release goals. That is still your responsibility.

Identify secondary/backup contact point. My Secondary Contact Point is: [email protected] (and/or GH Handle)

Write (code + tests + docs) then get them merged. ALL-PR-NUMBERS

Code needs to be disabled by default. Verified by code OWNERS

Minimal testing

Minimal docs

cc @kubernetes/docs on docs PR

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io

Update release notes

Beta

Testing is sufficient for beta

User docs with tutorials
- Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io
- cc @kubernetes/docs on docs PR
- cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Thorough API review

cc @kubernetes/api

Stable

docs/proposals/foo.md moved to docs/design/foo.md
- cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

Soak, load testing

detailed user docs and examples

cc @kubernetes/docs

cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.

As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
and sometimes http://github.com/kubernetes/contrib, or other repos.

When you are done with the code, apply the "code-complete" label.

When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
testing. They won't do detailed code review: that already happened when your PRs were reviewed.
When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

Write user docs and get them merged in.

User docs go into http://github.com/kubernetes/kubernetes.github.io.

When the feature has user docs, please add a comment mentioning @kubernetes/docs.

When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.