Skip to content

Latest commit

 

History

History
204 lines (157 loc) · 8.64 KB

README.md

File metadata and controls

204 lines (157 loc) · 8.64 KB

KEP-1687: Hierarchical Namespaces As A Subproject

Summary

Hierarchical Namespace Controller makes it easier for you to create and manage namespaces in your cluster. For example, you can create a hierarchical namespace under your team's namespace, even if you don't have cluster-level permission to create namespaces, and easily apply policies like RBAC and Network Policies across all namespaces in your team (e.g. a set of related microservices).

You can read more about hierarchical namespaces in the HNC Concepts doc.

Motivation

The Hierarchical Namespace Controller is currently being developed within the Multi-Tenancy Working Group, (of which Sig-Auth is the sponsor). As Working Groups are not meant to own code, and Hierarchical Namespace Controller is nearly to MVP status, a permant home is required. Additionally, having a permanent home for Hierarchical Namespace Controller prior to officially releasing will prevent cumbersome migrations of client libraries if a move were to happen at a later time.

Goals

Establish a new repository and permanent home for Hierarchical Namespace Controller at github.com/kubernetes-sigs/hierarchical-namespaces to be maintained by the open source Kubernetes community and governed as a subproject of sig-auth.

Proposal

The current multi-tenancy repository will be transferred directly. Subsequent pull requests will then remove HNC from the multi-tenancy repository and reorganize the new Hierarchical Namespace Controller repository as needed. The new source control location will become the authoritative source of truth for all issues and pull requests. As an independent subproject under sig-auth, Hierarchical Namespace Controller will continue to maintain the Apache license hosted here.

The following group of community members will serve as initial maintainers of the new repository:

  • @adrianludwin
  • @rjbez17

Maintainers will devote time to transfer, maintain, and release the Hierarchical Namespace Controller code base in a time bound manor. Maintainers will document features, blog, evangelize, and respond to the community on slack, groups, forums, etc. Maintainers will serve as the initial owners of the subproject.

Risks and Mitigations

There are no obvious risks with this proposal. Hierarchical Namespace Controller is currently in pre-alpha and has no apparent adoption.

Graduation Criteria

Intake

  • API and code quality review completed
  • API security review completed
  • Experimental warnings on the readme to indicate this is not an officially supported k8s-sigs product

Beta

  • Evidence of usage in the community
  • API promoted to v1beta1
  • All documentation, source control, tests and project roadmaps are updated and inline with sig standards
  • Commitment to follow regular Kubernetes API upgrade standards

Alternatives

Absorb Hierarchical Namespace Controller Into Another Project

There are no apparent alternative projects to absorb Hierarchical Namespace Controller. However, our stated goal is to find a permant home, regardless where it may be.

Hierarchical Namespace Controller Continues As A Non-Sig Project

The Hierarchical Namespace Controller is currently being developed within the Multi-Tenancy WG. This poses a problem because working groups are not meant to own code. As Sig-Auth is the sponsor for the Multi-Tenancy WG, it is fitting for it to move into a Sig-Auth subproject. All current code has been completed in a kubernetes-sig repository and has followed it's governance. Moving Hierarchical Namespace Controller to a different foundation or non-CNCF owner seems unfitting.

Abandon Hierarchical Namespace Controller

There is quite a bit of community interest for the Hierarchical Namespace Controller project to continue on. As we are still pre-alpha, this option would not affect production workloads. However, with eager maintainers and contributors, moving to a different foundation is far more preferable.

Implementation History

  • KEP created - April 14 2020
  • KEP updated to follow new process - April 14 2020
  • KEP updated formatting to make it easier to review - April 23 2020
  • KEP updated to include additional graduation criteria - April 28 2020
  • KEP updated with grammatical mistakes found in PR - May 5 2020
  • KEP updated with graduation criteria requested from reviewers - May 8 2020
  • KEP updated with status of implementable - Jan 6 2021