Merge pull request #733 from wking/installer-specific-operator-doc-focus

docs/dev/operators: Drop docs for the CVO approach

docs/dev/operators.md

@@ -2,52 +2,9 @@
 
 This document describes how to provide an operator's configuration files and manifests to installer-launched clusters.
 
-One can classify all the manifest/config files of an operator in two categories:
- - Static
- - Templatized
-
-The static ones are clearly just byte blobs and the templates are ones that have some variable that needs to be filled up. Typically the variables that need filling up will come from user preferences as specified in the install config (e.g. cluster name, cluster domain, service cidr etc). Other dependencies could be TLS cert keys for example.
-
 ## The recommended way
-The static and template files of your operator need to be dealt with separately.
-
-### Static files
-
-For static files use the Cluster Version Operator (CVO) payload mechanism. There is a particular way to keep the manifest files so that the CVO update payload can pick it up.
-See this document:
-
-https://github.com/openshift/cluster-version-operator/tree/master/docs/dev/operators.md
-
-Also remember that the order of creation of the files is alphabetical, so the files should be numbered like below to effectively create the service account before the deployment.
-```
-00-namespace.yaml
-...
-03-roles.yaml
-04-serviceaccount.yaml
-05-deployment.yaml
-```
-where, 04/05 is the internal ordering of the resource manifests.
-
-### What to do for the dynamic template files?
 
-An operator should auto-discover the install config rather than expand the templates through the installer integration (see alternative). Simply use the apiserver access to get the install-config as a config map. The config map is stored by the name ‘cluster-config-v1’ in the ‘kube-system’ namespaces.
-Pseudo code:
-```
-kube-client(apiserver-url).Get(Resource: "config-map", Namespace: "kube-system", Name: "cluster-config-v1")
-```
-where, apiserver-url is a cluster supplied ENV var ‘KUBERNETES_SERVICE_HOST’ in the pod.
-Example:
-
-https://github.com/openshift/machine-config-operator/blob/e932afdec07dc86d5b643590164f86811e205c57/pkg/operator/operator.go#L272
-
-After discovering the InstallConfig, the operator pod can do two things:
-
- - create its own configuration in memory as users should not be editing it
- - or, push the discovered config to an API as the operator's users might want to change it in the future
-
-See an example of the configuration for the operator being discovered rather than from a configmap:
-
-https://github.com/openshift/machine-config-operator/blob/31c20eefca172d5c1173e7b79b30bad540958dfe/pkg/operator/render.go#L46
+Most operators should use [the Cluster Version Operator (CVO) payload mechanism][cvo-operators].
 
 ## The alternative (for exceptions only)
 
@@ -60,3 +17,5 @@ Create a new operator asset, and render the Dependencies, Name, Load and Generat
 
  - Template files
 In the pkg/asset/manifests/content/tectonic directory, place the templates golang variables. Then modify pkg/asset/manifests/tectonic.go to expand the template. Expand templateData in template.go for filling up the template variables.
+
+[cvo-operators]: https://github.com/openshift/cluster-version-operator/tree/master/docs/dev/operators.md