add building without in tree providers

keps/sig-cloud-provider/20190729-building-without-in-tree-providers.md

@@ -0,0 +1,206 @@
+---
+title: Building Kubernetes Without In-Tree Cloud Providers
+authors:
+  - "@janedoe"
+owning-sig: sig-xxx
+participating-sigs:
+  - sig-cloud-provider
+  - sig-release
+reviewers:
+  - "@cheftako"
+  - "@andrewsykim"
+  - "@stephenaugustus"
+approvers:
+  - TBD
+editor: TBD
+creation-date: 2019-07-29
+last-updated: 2019-07-29
+status: provisional|implementable|implemented|deferred|rejected|withdrawn|replaced
+see-also:
+  - "/keps/sig-cloud-provider/20190125-removing-in-tree-providers.md"
+---
+
+# Building Kubernetes Without In-Tree Cloud Providers
+
+## Table of Contents
+
+<!-- toc -->
+- [Release Signoff Checklist](#release-signoff-checklist)
+- [Summary](#summary)
+- [Motivation](#motivation)
+  - [Goals](#goals)
+  - [Non-Goals](#non-goals)
+- [Proposal](#proposal)
+  - [User Stories [optional]](#user-stories-optional)
+    - [Story 1](#story-1)
+    - [Story 2](#story-2)
+  - [Implementation Details/Notes/Constraints [optional]](#implementation-detailsnotesconstraints-optional)
+  - [Risks and Mitigations](#risks-and-mitigations)
+- [Design Details](#design-details)
+  - [Test Plan](#test-plan)
+  - [Graduation Criteria](#graduation-criteria)
+    - [Examples](#examples)
+      - [Alpha -&gt; Beta Graduation](#alpha---beta-graduation)
+      - [Beta -&gt; GA Graduation](#beta---ga-graduation)
+      - [Removing a deprecated flag](#removing-a-deprecated-flag)
+  - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy)
+  - [Version Skew Strategy](#version-skew-strategy)
+- [Implementation History](#implementation-history)
+- [Drawbacks [optional]](#drawbacks-optional)
+- [Alternatives [optional]](#alternatives-optional)
+- [Infrastructure Needed [optional]](#infrastructure-needed-optional)
+<!-- /toc -->
+
+## Release Signoff Checklist
+
+- [ ] kubernetes/enhancements issue in release milestone, which links to KEP (this should be a link to the KEP location in kubernetes/enhancements, not the initial KEP PR)
+- [ ] KEP approvers have set the KEP status to `implementable`
+- [ ] Design details are appropriately documented
+- [x] Test plan is in place, giving consideration to SIG Architecture and SIG Testing input
+- [x] Graduation criteria is in place
+- [ ] "Implementation History" section is up-to-date for milestone
+- [ ] User-facing documentation has been created in [kubernetes/website], for publication to [kubernetes.io]
+- [ ] Supporting documentation e.g., additional design documents, links to mailing list discussions/SIG meetings, relevant PRs/issues, release notes
+
+## Summary
+
+This proposal outlines a plan to enable building Kubernetes without the in-tree
+cloud providers in preparation for [removing them entirely](keps/sig-cloud-provider/20190125-removing-in-tree-providers.md).
+
+## Motivation
+
+The in tree cloud-provider implementations are being [removed](keps/sig-cloud-provider/20190125-removing-in-tree-providers.md) in the future, this involves a large amount
+of code that is used in many places in tree. In order to prepare for this eventuality
+it would be helpful to see what that removal entails exactly and verify that Kubernetes
+will continue to function correctly. Doing so is a bit tricky without ensuring
+that the in-tree provider code is not being used via some unexpected side-channel
+(such as `init()` methods). Building binaries without the in-tree cloud provider
+packages would allow us to verify this and additionally provide experimentally
+smaller / cheaper binaries for parties interested in out of tree provider or 
+no provider based clusters.
+
+### Goals
+
+- Enable building Kubernetes without in-tree cloud providers and without forking
+  - Enable testing out of tree providers with a simulation of the future removal of the in-tree code.
+  - Enable experimentation with cloud-provider-less clusters
+
+### Non-Goals
+
+- Building the out of tree providers
+- Building the e2e tests 
+  - Decoupling cloud providers is a larger problem there and not necessary to test out-of-tree providers or build smaller binaries
+- Mechanisms for migrating to out of tree providers
+  - CSI Migration for in-tree Volumes is already underway in SIG Storage
+  - External Credential Providers is being written / solved in another KEP ([#541](https://github.com/kubernetes/enhancements/issues/541))
+  - CCMs and overall scope for moving out of tree is in [removing-in-tree-providers](keps/sig-cloud-provider/20190125-removing-in-tree-providers.md)
+
+## Proposal
+
+We will add a [build constraints](https://golang.org/pkg/go/build/#hdr-Build_Constraints)
+to the cloud provider code for a pseudo "build tag" specifying not to include
+any in-tree provider code. This will allow compiling the binaries as normal today
+and simulating the removal of this code by specifying the tag at build time and
+triggering the build constraints on the files in these packages.
+
+Some small adjustments may be necessary to the code base to ensure that the
+other packages can build without depending on these packages.
+
+A prototype is available in [kubernetes/kubernetes#80353](https://github.com/kubernetes/kubernetes/pull/80353).
+
+To ensure that this continues to function we will add CI building in this mode,
+and CI running end to end tests against it (see the test plan).
+
+### User Stories [optional]
+
+Detail the things that people will be able to do if this KEP is implemented.
+Include as much detail as possible so that people can understand the "how" of the system.
+The goal here is to make this feel real for users without getting bogged down.
+
+#### Story 1
+
+#### Story 2
+
+### Implementation Details/Notes/Constraints [optional]
+
+What are the caveats to the implementation?
+What are some important details that didn't come across above.
+Go in to as much detail as necessary here.
+This might be a good place to talk about core concepts and how they releate.
+
+### Risks and Mitigations
+
+What are the risks of this proposal and how do we mitigate.
+Think broadly.
+For example, consider both security and how this will impact the larger kubernetes ecosystem.
+
+How will security be reviewed and by whom?
+How will UX be reviewed and by whom?
+
+Consider including folks that also work outside the SIG or subproject.
+
+## Design Details
+
+### Test Plan
+
+We will add CI to ensure that we can build with this mode enabled.
+
+Additionally, we can add CI to ensure that clusters can actually be started in
+this mode.
+
+Initially, [kind](https://github.com/kubernetes-sigs/kind) can be used to ensure
+that Kubernetes works without the providers, in the future we can extend this
+CI to out-of-tree providers combined with this build mode as their CI is spun up.
+
+### Graduation Criteria
+
+##### Alpha -> Beta Graduation
+
+Likely unnecessary, as we will eventually remove the in-tree provider code entirely for [removing-in-tree-providers](keps/sig-cloud-provider/20190125-removing-in-tree-providers.md).
+
+##### Beta -> GA Graduation
+
+Likely unnecessary, as we will eventually remove the in-tree provider code entirely for  [removing-in-tree-providers](keps/sig-cloud-provider/20190125-removing-in-tree-providers.md).
+
+### Upgrade / Downgrade Strategy
+
+N/A ?
+
+### Version Skew Strategy
+
+N/A ?
+
+## Implementation History
+
+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
+
+## Drawbacks [optional]
+
+This does require maintaining these tags / constraints for the providerless build,
+however in the default mode without our pseudo-tag the code will build as today
+and require zero additional maintenance to function. As in-tree providers are
+relatively stable and expected not to gain new features, this should require
+minimal effort and can be automated to a limited extent.
+
+## Alternatives [optional]
+
+We could simply wait for the in-tree providers to be removed entirely, however
+this may not provide sufficient tools to adequately prepare.
+
+## Infrastructure Needed [optional]
+
+None?
+
+[kubernetes.io]: https://kubernetes.io/
+[kubernetes/enhancements]: https://github.com/kubernetes/enhancements/issues
+[kubernetes/kubernetes]: https://github.com/kubernetes/kubernetes
+[kubernetes/website]: https://github.com/kubernetes/website
+