Move provider Cloud Controller Manager repo reqs to kep
Moves the recently approved provider Cloud Controller Manager repository requirements to the Cloud Controller Manager kep. Also integrates corrections and clarifications from WG-Cloud-Provider.
This commit is contained in:
Chris Hoge
parent
4f9bc566a9
commit
d7a1966523
|
|
@ -4,6 +4,7 @@ title: Cloud Provider Controller Manager
|
|||
authors:
|
||||
- "@cheftako"
|
||||
- "@calebamiles"
|
||||
- "@hogepodge"
|
||||
owning-sig: sig-apimachinery
|
||||
participating-sigs:
|
||||
- sig-apps
|
||||
|
|
@ -41,10 +42,15 @@ replaces:
|
|||
- [API Server Changes](#api-server-changes)
|
||||
- [Volume Management Changes](#volume-management-changes)
|
||||
- [Deployment Changes](#deployment-changes)
|
||||
- [Implementation Details/Notes/Constraints](#implementation-detailsnotesconstraints)
|
||||
- [Repository Requirements](#repository-requirements)
|
||||
- [Notes for Repository Requirements](#notes-for-repository-requirements)
|
||||
- [Repository Timeline](#repository-timeline)
|
||||
- [Security Considerations](#security-considerations)
|
||||
- [Graduation Criteria](#graduation-criteria)
|
||||
- [Graduation to Beta](#graduation-to-beta)
|
||||
- [Process Goals](#process-goals)
|
||||
- [Implementation History](#implementation-history)
|
||||
- [Alternatives](#alternatives)
|
||||
|
||||
## Summary
|
||||
|
|
@ -208,8 +214,8 @@ taints.
|
|||
|
||||
### API Server Changes
|
||||
|
||||
Finally, in the kube-apiserver, the cloud provider is used for transferring SSH keys to all of the nodes, and within an a
|
||||
dmission controller for setting labels on persistent volumes.
|
||||
Finally, in the kube-apiserver, the cloud provider is used for transferring SSH keys to all of the nodes, and within an
|
||||
admission controller for setting labels on persistent volumes.
|
||||
|
||||
Kube-apiserver uses the cloud provider for two purposes
|
||||
|
||||
|
|
@ -257,6 +263,102 @@ In case of the cloud-controller-manager, the deployment should be deleted using
|
|||
kubectl delete -f cloud-controller-manager.yml
|
||||
```
|
||||
|
||||
### Implementation Details/Notes/Constraints
|
||||
|
||||
#### Repository Requirements
|
||||
|
||||
**This is a proposed structure, and may change during the 1.11 release cycle.
|
||||
WG-Cloud-Provider will work with individual sigs to refine these requirements
|
||||
to maintain consistency while meeting the technical needs of the provider
|
||||
maintainers**
|
||||
|
||||
Each cloud provider hosted within the `kubernetes` organization shall have a
|
||||
single repository named `kubernetes/cloud-provider-<provider_name>`. Those
|
||||
repositories shall have the following structure:
|
||||
|
||||
* A `cloud-controller-manager` subdirectory that contains the implementation
|
||||
of the provider-specific cloud controller.
|
||||
* A `docs` subdirectory.
|
||||
* A `docs/cloud-controller-manager.md` file that describes the options and
|
||||
usage of the cloud controller manager code.
|
||||
* A `docs/testing.md` file that describes how the provider code is tested.
|
||||
* A `Makefile` with a `test` entrypoint to run the provider tests.
|
||||
|
||||
Additionally, the repository should have:
|
||||
|
||||
* A `docs/getting-started.md` file that describes the installation and basic
|
||||
operation of the cloud controller manager code.
|
||||
|
||||
Where the provider has additional capabilities, the repository should have
|
||||
the following subdirectories that contain the common features:
|
||||
|
||||
* `dns` for DNS provider code.
|
||||
* `cni` for the Container Network Interface (CNI) driver.
|
||||
* `csi` for the Container Storage Interface (CSI) driver.
|
||||
* `flex` for the Flex Volume driver.
|
||||
* `installer` for custom installer code.
|
||||
|
||||
Each repository may have additional directories and files that are used for
|
||||
additional feature that include but are not limited to:
|
||||
|
||||
* Other provider specific testing.
|
||||
* Additional documentation, including examples and developer documentation.
|
||||
* Dependencies on provider-hosted or other external code.
|
||||
|
||||
|
||||
##### Notes for Repository Requirements
|
||||
|
||||
This purpose of these requirements is to define a common structure for the
|
||||
cloud provider repositories owned by current and future cloud provider SIGs.
|
||||
In accordance with the
|
||||
[WG-Cloud-Provider Charter](https://docs.google.com/document/d/1m4Kvnh_u_9cENEE9n1ifYowQEFSgiHnbw43urGJMB64/edit#)
|
||||
to "define a set of common expected behaviors across cloud providers", this
|
||||
proposal defines the location and structure of commonly expected code.
|
||||
|
||||
As each provider can and will have additional features that go beyond expected
|
||||
common code, requirements only apply to the location of the
|
||||
following code:
|
||||
|
||||
* Cloud Controller Manager implementations.
|
||||
* Documentation.
|
||||
|
||||
This document may be amended with additional locations that relate to enabling
|
||||
consistent upstream testing, independent storage drivers, and other code with
|
||||
common integration hooks may be added
|
||||
|
||||
The development of the
|
||||
[Cloud Controller Manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)
|
||||
and
|
||||
[Cloud Provider Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)
|
||||
has enabled the provider SIGs to develop external providers that
|
||||
capture the core functionality of the upstream providers. By defining the
|
||||
expected locations and naming conventions of where the external provider code
|
||||
is, we will create a consistent experience for:
|
||||
|
||||
* Users of the providers, who will have easily understandable conventions for
|
||||
discovering and using all of the providers.
|
||||
* SIG-Docs, who will have a common hook for building or linking to externally
|
||||
managed documentation
|
||||
* SIG-Testing, who will be able to use common entry points for enabling
|
||||
provider-specific e2e testing.
|
||||
* Future cloud provider authors, who will have a common framework and examples
|
||||
from which to build and share their code base.
|
||||
|
||||
##### Repository Timeline
|
||||
|
||||
To facilitate community development, providers named in the
|
||||
[Makes SIGs responsible for implementations of `CloudProvider`](https://github.com/kubernetes/community/pull/1862)
|
||||
patch can immediately migrate their external provider work into their named
|
||||
repositories.
|
||||
|
||||
Each provider will work to implement the required structure during the
|
||||
Kubernetes 1.11 development cycle, with conformance by the 1.11 release.
|
||||
WG-Cloud-Provider may actively change repository requirements during the
|
||||
1.11 release cycle to respond to collective SIG technical needs.
|
||||
|
||||
After the 1.11 release all current and new provider implementations must
|
||||
conform with the requirements outlined in this document.
|
||||
|
||||
### Security Considerations
|
||||
|
||||
Make sure that you consider the impact of this feature from the point of view of Security.
|
||||
|
|
@ -307,6 +409,20 @@ is proposed to
|
|||
- serve as a repository for user experience reports related to Cloud Providers
|
||||
which live within the Kubernetes GitHub organization or desire to do so
|
||||
|
||||
Major milestones:
|
||||
|
||||
- March 18, 2018: Accepted proposal for repository requirements.
|
||||
|
||||
*Major milestones in the life cycle of a KEP should be tracked in `Implementation History`.
|
||||
Major milestones might include
|
||||
|
||||
- the `Summary` and `Motivation` sections being merged signaling SIG acceptance
|
||||
- the `Proposal` section being merged signaling agreement on a proposed design
|
||||
- the date implementation started
|
||||
- the first Kubernetes release where an initial version of the KEP was available
|
||||
- the version of Kubernetes where the KEP graduated to general availability
|
||||
- when the KEP was retired or superseded*
|
||||
|
||||
The ultimate intention of WG Cloud Provider is to prevent multiple classes
|
||||
of software purporting to be an implementation of the Cloud Provider interface
|
||||
from fracturing the Kubernetes Community while also ensuring that new Cloud
|
||||
|
|
|
|||
|
|
@ -1,87 +0,0 @@
|
|||
# Conventions for Cloud Provider Repositories
|
||||
|
||||
This purpose of this document is to define a common structure for the cloud
|
||||
provider repositories owned by current and future cloud provider SIGs[1]. In
|
||||
accordance with the WG-Cloud-Provider Charter[2] to "define a set of common
|
||||
expected behaviors across cloud providers", this proposal defines the location
|
||||
and structure of commonly expected code.
|
||||
|
||||
As each provider can and will have additional features that go beyond expected
|
||||
common code, this document is only prescriptive to the location of the
|
||||
following code:
|
||||
|
||||
* Cloud Controller Manager implementations.
|
||||
* Documentation.
|
||||
|
||||
This document may be amended with additional locations that relate to enabling
|
||||
consistent upstream testing, independent storage drivers, and other code with
|
||||
common integration hooks may be added
|
||||
|
||||
## Motivation
|
||||
|
||||
The development of the Cloud Controller Manager[3] and Cloud Provider
|
||||
Interface[4] has enabled the provider SIGs to develop external providers that
|
||||
capture the core functionality of the upstream providers. By defining the
|
||||
expected locations and naming conventions of where the external provider code
|
||||
is, we continue in creating a consistent experience for:
|
||||
|
||||
* Users of the providers, who will have easily understandable conventions for
|
||||
discovering and using all of the providers.
|
||||
* SIG-Docs, who will have a common hook for building or linking to externally
|
||||
managed documentation
|
||||
* SIG-Testing, who will be able to use common entry points for enabling
|
||||
provider-specific e2e testing.
|
||||
* Future cloud provider authors, who will have a common framework and examples
|
||||
from which to build and share their code base.
|
||||
|
||||
## Requirements
|
||||
|
||||
Each cloud provider hosted within the `kubernetes` organization shall have a
|
||||
single repository named `kubernetes/cloud-provider-<provider_name>`. Those
|
||||
repositories shall have the following structure:
|
||||
|
||||
* A `cloud-controller-manager` subdirectory that contains the implementation
|
||||
of the provider-specific cloud controller.
|
||||
* A `docs` subdirectory.
|
||||
* A `docs/cloud-controller-manager.md` file that describes the options and
|
||||
usage of the cloud controller manager code.
|
||||
* A `tests` subdirectory that contains testing code.
|
||||
|
||||
Additionally, the repository should have:
|
||||
|
||||
* A `docs/getting-started.md` file that describes the installation and basic
|
||||
operation of the cloud controller manager code.
|
||||
|
||||
Where the provider has additional capabilities, the repository should have
|
||||
the following subdirectories that contain the common features:
|
||||
|
||||
* `dns` for DNS provider code.
|
||||
* `cni` for the Container Network Interface (CNI) driver.
|
||||
* `flex` for the Flex Volume driver.
|
||||
* `installer` for custom installer code.
|
||||
|
||||
Each repository may have additional directories and files that are used for
|
||||
additional feature that include but are not limited to:
|
||||
|
||||
* Other provider specific testing.
|
||||
* Additional documentation, including examples and developer documentation.
|
||||
* Dependencies on provider-hosted or other external code.
|
||||
|
||||
## Timeline
|
||||
|
||||
To facilitate community development, providers named in the `Make SIGs
|
||||
responsible for implementations of CloudProvider` patch[1] can immediately
|
||||
migrate their external provider work into their named repositories.
|
||||
|
||||
Each provider will work to implement the required structure during the
|
||||
Kubernetes 1.11 development cycle, with conformance by the 1.11 release.
|
||||
|
||||
After the 1.11 release all current and new provider implementations must
|
||||
conform with the requirements outlined in this document.
|
||||
|
||||
## References
|
||||
|
||||
1. [Makes SIGs responsible for implementations of `CloudProvider`](https://github.com/kubernetes/community/pull/1862)
|
||||
2. [Cloud Provider Working Group Proposal](https://docs.google.com/document/d/1m4Kvnh_u_9cENEE9n1ifYowQEFSgiHnbw43urGJMB64/edit#)
|
||||
3. [Cloud Controller Manager](https://github.com/kubernetes/kubernetes/tree/master/cmd/cloud-controller-manager)
|
||||
4. [Cloud Provider Interface](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/cloud.go)
|
||||
Loading…
Reference in New Issue