Updates

Author: detiber

docs/proposals/20191017-control-plane.md renamed to docs/proposals/20191017-kubeadm-based-control-plane.md

@@ -1,5 +1,5 @@
 ---
-title: Control Plane Management
+title: Kubeadm Based Control Plane Management
 authors:
   - "@detiber”
   - "@chuckha”
@@ -17,11 +17,11 @@ reviewers:
   - "@hardikdr"
   - "@sbueringer"
 creation-date: 2019-10-17
-last-updated: 2019-10-30
+last-updated: 2019-11-08
 status: implementable
 ---
 
-# Control Plane Management
+# Kubeadm Based Control Plane Management
 
 ## Table of Contents
 
@@ -88,12 +88,9 @@ and centralize the logic in Cluster API.
 ### Goals
 
 - To establish new resource types for control plane management
-- To support single node and multiple control plane instances, with the requirement that the infrastructure provider supports some type of a stable endpoint for the API Server (Load Balancer, VIP, etc).
+- To support single node and multiple node control plane instances, with the requirement that the infrastructure provider supports some type of a stable endpoint for the API Server (Load Balancer, VIP, etc).
 - To enable declarative orchestrated control plane upgrades
 - To provide a default machine-based implementation using kubeadm
-
-#### Additional goals of the default kubeadm machine-based Implementation
-
 - To provide a kubeadm-based implementation that is infrastructure provider agnostic
 - To enable declarative orchestrated replacement of control plane machines, such as to rollout an OS-level CVE fix.
 - To manage a kubeadm-based, "stacked etcd" control plane
@@ -107,9 +104,10 @@ and centralize the logic in Cluster API.
 Non-Goals listed in this document are intended to scope bound the current v1alpha3 implementation and are subject to change based on user feedback over time.
 
 - To manage non-machine based topologies, e.g.
-  - Pod based control planes; these can be managed via standard kubernetes objects.
-  - Non-node control planes (i.e. EKS, GKE, AKS); these can be managed via the respective APIs.
-- To manage control plane deployments across failure domains, followup work for this will be tracked on [this issue](https://github.com/kubernetes-sigs/cluster-api/issues/1647).
+  - Pod based control planes.
+  - Non-node control planes (i.e. EKS, GKE, AKS).
+- To manage control plane deployments across failure domains, follow up work for this will be tracked on [this issue](https://github.com/kubernetes-sigs/cluster-api/issues/1647).
+- To define a mechanism for providing a stable API endpoint for providers that do not currently have one, follow up work for this will be tracked on [this issue](https://github.com/kubernetes-sigs/cluster-api/issues/1687)
 - To manage CA certificates outside of what is provided by Kubeadm bootstrapping
 - To manage etcd clusters in any topology other than stacked etcd (externally managed etcd clusters can still be leveraged).
 - To address disaster recovery constraints, e.g. restoring a control plane from 0 replicas using a filesystem or volume snapshot copy of data persisted in etcd.
@@ -142,7 +140,7 @@ Non-Goals listed in this document are intended to scope bound the current v1alph
 
 1. Based on the function of kubeadm, the control plane provider must be able to scale the number of replicas of a control plane from 1 to X, meeting user stories 1 through 4.
 2. To address user story 5, the control plane provider must provide validation of the number of replicas in a control plane. Where the stacked etcd topology is used (i.e., in the default implementation), the number of replicas must be an odd number, as per [etcd best practice](https://etcd.io/docs/v3.3.12/faq/#why-an-odd-number-of-cluster-members). When external etcd is used, any number is valid.
-3. In service of user story 5, the control plane provider must also manage etcd membership via kubeadm as part of scaling down (`kubeadm` takes care of adding the new etcd member when joining).
+3. In service of user story 5, the kubeadm control plane provider must also manage etcd membership via kubeadm as part of scaling down (`kubeadm` takes care of adding the new etcd member when joining).
 4. The control plane provider should provide indicators of health to meet user story 6 and 10. This should include at least the state of etcd and information about which replicas are currently healthy or not. For the default implementation, health attributes based on artifacts kubeadm installs on the cluster may also be of interest to cluster operators.
 5. The control plane provider must be able to upgrade a control plane’s version of Kubernetes as well as updating the underlying machine image on where applicable (e.g. virtual machine based infrastructure).