edit proposal; update figure

Author: charleszheng44

proposals/20201026-creating-control-plane-components.md

@@ -155,61 +155,19 @@ type NestedControlPlaneSpec struct {
 }
 ```
 
-After applying the NCP CR, the NCP controller will find the three associated components and set their `metav1.OwnerReference` as the NCP CR. Then, when creating the component workload, the component controller can find other CRs through the owner NCP.
+After applying the NCP CR, the NCP controller will find the three associated components and set their `metav1.OwnerReference` as the NCP CR. Then, the component controller can find other CRs through the owner NCP, when creating the component workload.
 
 ### Creation
-End-users can create component CRs manually and apply them to the cluster with an NCP to create the resources. In the future, we might introduce the `Template` CR, which will handle the creation of the component CRs in it's controller. If the end-user intend to use out-of-tree controllers, they can specify them in the NCP spec, we define three new types:
 
-```go
-type NestedKASProvider string
-
-type NestedEtcdProvider string
-
-type NestedKCMProvider string
-
-const (
-    NativeKASProvider NestedKASProvider = "NativeKASProvider"
-
-    NativeEtcdProvider  NestedEtcdProvider = "NativeEtcdProvider"
-    EtcdClusterOperator NestedEtcdProvider = "EtcdClusterOperator"
-    EtcdOperator        NestedEtcdProvider = "EtcdOperator"
-
-    NativeKCMProvider NestedKCMProvider = "NativeKCMProvider"
-) 
-```
+End-users can create component CRs manually and apply them to the cluster with an NCP to create the resources. In the future, we might introduce the `Template` CR, which will handle the creation of the component CRs in it's controller. We assume that at any given time, there will be only component controller for each component, and it is cluster administrator's responsibility to setup the proper component controllers. 
 
-and adds three new fields into the NCP spec:
+#### In-tree
 
-```go
-type NestedControlPlaneSpec struct {
-    // other fields ...
-
-    // EtcdProvider specifies which EtcdProvider will be used to create the Etcd
-    // +optional
-    EtcdProvider NestedEtcdProvider `json:"etcdProvider,omitempty"`
-     
-    // ApiServerProvider specifies which KASProvider will be used to create the kube-apiserver
-    // +optional
-    ApiServerProvider NestedKASProvider `json:"apiServerProvider,omitempty"`
- 
-    // ControllerManagerProvider specifies which KCMProvider will be used to create the kube-controller-manager
-    // +optional
-    ControllerManagerProvider NestedKCMProvider `json:"controllerManagerProvider,omitempty"`
-}
-```
-
-
-#### Native way 
-
-If no component provider is specified, the component controller will create the component under the native mode, which will create the component using the default manifests. The readiness and liveness probe will be used, and we will mark each component as ready only when the corresponding workload is ready. As the KAS cannot work without available Etcd and the KCM cannot run without KAS, the three components need to be created by their respective controllers in the order of Etcd, KAS, and KCM. Creation order is maintained using cross resource status checks to "wait" until the dependencies are provisioned before booting.
-
-Except using `OwnerReference` and `CAPI.Status.Selector`, another option of sharing status across components are adding initContainer to each component. The component controllers will then create the component workload without polling the status of other CRs while having the initContainer to check and wait for other components to be ready. 
-
-We will host sets of default templates in this repositor. Users can specify which set of templates they intend to use by specifying the corresponding `version` or `channel` in the embedded `CommonSpec` in the component's CR.
+The component controller will create the component under the in-tree mode, which will create the component using the default manifests. The readiness and liveness probe will be used, and we will mark each component as ready only when the corresponding workload is ready. As the KAS cannot work without available Etcd and the KCM cannot run without KAS, the three components need to be created by their respective controllers in the order of Etcd, KAS, and KCM. Creation order is maintained using cross resource status checks to "wait" until the dependencies are provisioned before booting. We will host sets of default templates in this repository. Users can specify which set of templates they intend to use by specifying the corresponding `version` or `channel` in the embedded `CommonSpec` in the component's CR.
 
 Each component's controller will generate necessary certificates for the component and store them to the [secret resources](https://cluster-api.sigs.k8s.io/tasks/certs/using-custom-certificates.html) defined by CAPI. Also, The KAS controller will store the content of the kubeconfig file in a secret named `[clustername]-kubeconfig`.
 
-![Control Plane Creating Process](nativeway.png)
+![Control Plane Creating Process](in-tree.png)
 
 The creating process will include six steps:
 
@@ -225,24 +183,27 @@ The creating process will include six steps:
 
 #### Using out-of-tree provisioners
 
-If users intend to use an external component controller, they can disable any or all of the component controllers within the CAPN Manager. For example, if you wanted to use the [etcd-cluster-operator](https://github.com/improbable-eng/etcd-cluster-operator) this requires the [EtcdCluster](https://github.com/improbable-eng/etcd-cluster-operator/blob/master/api/v1alpha1/etcdcluster_types.go) CR. To support this you would implement a custom controller that listens for `Etcd` resource and will create the necessary CRs for that implementation and update the required status fields on `Etcd` to allow dependent services to be provisioned. This can be done using the [kubebuilder-declarative-pattern](https://github.com/kubernetes-sigs/kubebuilder-declarative-pattern) like is done for in-tree component controllers.
+If users intend to use an external component controller, they can disable any or all of the component controllers within the CAPN Manager. For example, if you wanted to use the [etcd-cluster-operator](https://github.com/improbable-eng/etcd-cluster-operator) this requires the [EtcdCluster](https://github.com/improbable-eng/etcd-cluster-operator/blob/master/api/v1alpha1/etcdcluster_types.go) CR. To support this you would implement a custom controller that listens for `NestedEtcd` resource and will create the necessary CRs for that implementation and update the required status fields on `NestedEtcd` to allow dependent services to be provisioned. This can be done using the [kubebuilder-declarative-pattern](https://github.com/kubernetes-sigs/kubebuilder-declarative-pattern) like is done for in-tree component controllers.
 
-In the following example, we assume that the user intend to use Etcd-cluster-operator(ECO) as the Etcd controller, and an ECO controller has been deployed on the super cluster. The creating process will include seven steps:
 ![Creating a Control Plane using out-of-tree provisioners](out-of-tree.png)
 
-1. The user generates all CRs and apply them.  
+In the following example, we assume that the user intend to use Etcd-cluster-operator(ECO) as the Etcd controller. The creating process will include seven steps:
+
+1. The cluster administrator deletes the in-tree Etcd controller and deploys the custom Etcd controller (ECO controller).
+
+2. The user generates all CRs and apply them.  
 
-2. As the user chooses to use the etcd-cluster-operator(ECO), the ECO controller will create the EtcdCluster CR
+3. As the user chooses to use the etcd-cluster-operator(ECO), the ECO controller will create the EtcdCluster CR.
 
-3. The ECO creates the Etcd workload.
+4. The ECO creates the Etcd workload.
 
-4. At the meantime, the ECO controller keeps watching the EtcdCluster CR, stores the Etcd CA into the `secret/[cluster-name]-etcd`, and update the `Etcd` CR accordingly.
+5. At the meantime, the ECO controller keeps watching the EtcdCluster CR, stores the Etcd CA into the `secret/[cluster-name]-etcd`, and update the `Etcd` CR accordingly.
 
-5. The KAS controller creates the KAS service, generates certificates, creates the KAS workload, stores certificates into `secret/[cluster-name]-ca`, creates the kubeconfig and stores it into the `secret/[cluster-name]-kubeconfig`
+6. The KAS controller creates the KAS service, generates certificates, creates the KAS workload, stores certificates into `secret/[cluster-name]-ca`, creates the kubeconfig and stores it into the `secret/[cluster-name]-kubeconfig`
 
-6. The KCM controller generates the KCM kubeconfig and creates the KCM workload.
+7. The KCM controller generates the KCM kubeconfig and creates the KCM workload.
 
-7. Once all the three components are ready, the NCP controller marks the NCP CR as ready.
+8. Once all the three components are ready, the NCP controller marks the NCP CR as ready.
 
 ### Control Plane Custom Resources 
 
@@ -273,7 +234,7 @@ type NestedEtcdStatus struct {
     Addresses []NestedEtcdAddress `json:"addresses,omitempty"`
 
     // CommonStatus allows addons status monitoring 
-    CommonStatus addonv1alpha1. CommonStatus `json:",inline"`
+    addonv1alpha1. CommonStatus `json:",inline"`
 }
 
 // EtcdAddress defines the observed addresses for etcd
@@ -326,7 +287,7 @@ type NestedAPIServerStatus struct {
     APIServerService *corev1.ObjectReference `json:"apiserverService,omitempty"`
 
     // CommonStatus allows addons status monitoring 
-    CommonStatus addonv1alpha1. CommonStatus `json:",inline"`
+    addonv1alpha1. CommonStatus `json:",inline"`
 }
 
 // NestedAPIServer is the Schema for the APIServers API
@@ -361,7 +322,7 @@ type NestedControllerManagerStatus struct {
     ProviderObject *corev1.ObjectReference `json:referralObject,omitempty`
 
     // CommonStatus allows addons status monitoring 
-    CommonStatus addonv1alpha1. CommonStatus `json:",inline"`
+    addonv1alpha1. CommonStatus `json:",inline"`
 }
 
 // NestedControllerManager is the Schema for the ControllerManagers API