kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #1942 from hogepodge/cloud-controller-manager 

Move provider Cloud Controller Manager repo requirements to KEP
This commit is contained in:
k8s-ci-robot 2018-05-15 12:48:28 -07:00 committed by GitHub
parent 57f8e9d90f d7a1966523
commit 1bb41093b6
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 118 additions and 89 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

120
keps/0002-controller-manager.md
View File

@ -4,6 +4,7 @@ title: Cloud Provider Controller Manager
authors: authors:
- "@cheftako" - "@cheftako"
- "@calebamiles" - "@calebamiles"
- "@hogepodge"
owning-sig: sig-apimachinery owning-sig: sig-apimachinery
participating-sigs: participating-sigs:
- sig-apps - sig-apps
@ -41,10 +42,15 @@ replaces:
- [API Server Changes](#api-server-changes) - [API Server Changes](#api-server-changes)
- [Volume Management Changes](#volume-management-changes) - [Volume Management Changes](#volume-management-changes)
- [Deployment Changes](#deployment-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) - [Security Considerations](#security-considerations)
- [Graduation Criteria](#graduation-criteria) - [Graduation Criteria](#graduation-criteria)
- [Graduation to Beta](#graduation-to-beta) - [Graduation to Beta](#graduation-to-beta)
- [Process Goals](#process-goals) - [Process Goals](#process-goals)
- [Implementation History](#implementation-history)
- [Alternatives](#alternatives) - [Alternatives](#alternatives)
## Summary ## Summary
@ -208,8 +214,8 @@ taints.
### API Server Changes ### 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 Finally, in the kube-apiserver, the cloud provider is used for transferring SSH keys to all of the nodes, and within an
dmission controller for setting labels on persistent volumes. admission controller for setting labels on persistent volumes.
Kube-apiserver uses the cloud provider for two purposes 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 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 ### Security Considerations
Make sure that you consider the impact of this feature from the point of view of Security. 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 - serve as a repository for user experience reports related to Cloud Providers
which live within the Kubernetes GitHub organization or desire to do so 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 The ultimate intention of WG Cloud Provider is to prevent multiple classes
of software purporting to be an implementation of the Cloud Provider interface of software purporting to be an implementation of the Cloud Provider interface
from fracturing the Kubernetes Community while also ensuring that new Cloud from fracturing the Kubernetes Community while also ensuring that new Cloud

87
wg-cloud-provider/cloud-provider-requirements.md
View File

@ -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)