[release-1.1] Clean up operator configmap docs

config/nav.yml

@@ -41,6 +41,7 @@ nav:
       # Operator Installation
       - Install with Knative Operator:
         - Installing with the Operator: install/operator/knative-with-operators.md
+        - Configuring Knative by using the Operator: install/operator/configuring-with-operator.md
         - Configuring Knative Eventing CRDs: install/operator/configuring-eventing-cr.md
         - Configuring Knative Serving CRDs: install/operator/configuring-serving-cr.md
       # kn Installation

docs/install/operator/configuring-eventing-cr.md

@@ -1,11 +1,3 @@
----
-title: "Configuring the Eventing Operator custom resource"
-weight: 60
-type: "docs"
-aliases:
-- /docs/operator/configuring-eventing-cr/
----
-
 # Configuring the Eventing Operator custom resource
 
 You can configure the Knative Eventing operator by modifying settings in the KnativeEventing custom resource (CR).
@@ -36,16 +28,6 @@ If Knative Eventing is already managed by the Operator, updating the `spec.versi
 Note that the Knative Operator only permits upgrades or downgrades by one minor release version at a time. For example,
 if the current Knative Eventing deployment is version 0.18.x, you must upgrade to 0.19.x before upgrading to 0.20.x.
 
-## Configuring Knative Eventing using ConfigMaps
-
-The Operator manages the Knative Eventing installation. It overwrites any updates to ConfigMaps which are used to configure Knative Eventing.
-The KnativeEventing CR allows you to set values for these ConfigMaps by using the Operator.
-
-All Knative Eventing ConfigMaps are created in the same namespace as the KnativeEventing CR. You can use the KnativeEventing CR as a unique entry point to edit all ConfigMaps.
-
-Knative Eventing has multiple ConfigMaps that are named with the prefix `config-`.
-The `spec.config` in the KnativeEventing CR has one `<name>` entry for each ConfigMap, named `config-<name>`, with a value which will be used for the ConfigMap `data`.
-
 ### Setting a default channel
 
 If you are using different channel implementations, like the KafkaChannel, or you want a specific configuration of the InMemoryChannel to be the default configuration, you can change the default behavior by updating the `default-ch-webhook` ConfigMap.

docs/install/operator/configuring-serving-cr.md

@@ -3,7 +3,6 @@
 The Knative Serving Operator can be configured with the following options:
 
 - [Version configuration](#version-configuration)
-- [Knative Serving configuration by ConfigMap](#knative-serving-configuration-by-configmap)
 - [Private repository and private secret](#private-repository-and-private-secrets)
 - [SSL certificate for controller](#ssl-certificate-for-controller)
 - [Replace the default istio-ingressgateway service](#replace-the-default-istio-ingressgateway-service)
@@ -37,68 +36,6 @@ enables upgrading or downgrading the Knative Serving version, without needing to
 !!! important
     The Knative Operator only permits upgrades or downgrades by one minor release version at a time. For example, if the current Knative Serving deployment is version v0.22.0, you must upgrade to v0.23.0 before upgrading to v0.24.0.
 
-## Knative Serving configuration by ConfigMap
-
-The Operator manages the Knative Serving installation. It overwrites any updates to ConfigMaps which are used to configure Knative Serving.
-The KnativeServing custom resource (CR) allows you to set values for these ConfigMaps by using the Operator.
-Knative Serving has multiple ConfigMaps that are named with the prefix `config-`.
-The `spec.config` in the KnativeServing CR has one `<name>` entry for each ConfigMap, named `config-<name>`, with a value which will be used for the ConfigMap `data`.
-
-In the [setup a custom domain example](../../serving/using-a-custom-domain.md), you can see the content of the ConfigMap
-`config-domain` is:
-
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: config-domain
-  namespace: knative-serving
-data:
-  example.org: |
-    selector:
-      app: prod
-  example.com: ""
-```
-
-Using the operator, specify the ConfigMap `config-domain` using the operator CR:
-
-```yaml
-apiVersion: operator.knative.dev/v1alpha1
-kind: KnativeServing
-metadata:
-  name: knative-serving
-  namespace: knative-serving
-spec:
-  config:
-    domain:
-      example.org: |
-        selector:
-          app: prod
-      example.com: ""
-```
-
-You can apply values to multiple ConfigMaps. This example sets `stable-window` to 60s in `config-autoscaler` as well as specifying `config-domain`:
-
-```yaml
-apiVersion: operator.knative.dev/v1alpha1
-kind: KnativeServing
-metadata:
-  name: knative-serving
-  namespace: knative-serving
-spec:
-  config:
-    domain:
-      example.org: |
-        selector:
-          app: prod
-      example.com: ""
-    autoscaler:
-      stable-window: "60s"
-```
-
-All the ConfigMaps are created in the same namespace as the operator CR. You can use the operator CR as the
-unique entry point to edit all of them.
-
 ## Private repository and private secrets
 
 You can use the `spec.registry` section of the operator CR to change the image references to point to a private registry or [specify imagePullSecrets](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod):

docs/install/operator/configuring-with-operator.md

@@ -0,0 +1,50 @@
+# Configuring Knative by using the Operator
+
+The Operator manages the configuration of a Knative installation, including propagating values from the `KnativeServing` and `KnativeEventing` custom resources to system [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/).
+
+Any updates to ConfigMaps which are applied manually are overwritten by the Operator. However, modifying the Knative custom resources allows you to set values for these ConfigMaps.
+
+Knative has multiple ConfigMaps that are named with the prefix `config-`.
+
+
+All Knative ConfigMaps are created in the same namespace as the custom resource that they apply to. For example, if the `KnativeServing` custom resource is created in the `knative-serving` namespace, all Knative Serving ConfigMaps are also created in this namespace.
+
+The `spec.config` in the Knative custom resources have one `<name>` entry for each ConfigMap, named `config-<name>`, with a value which is be used for the ConfigMap `data`.
+
+## Examples
+
+You can specify that the `KnativeServing` custom resource uses the `config-domain` ConfigMap  as follows:
+
+```yaml
+apiVersion: operator.knative.dev/v1alpha1
+kind: KnativeServing
+metadata:
+  name: knative-serving
+  namespace: knative-serving
+spec:
+  config:
+    domain:
+      example.org: |
+        selector:
+          app: prod
+      example.com: ""
+```
+
+You can apply values to multiple ConfigMaps. This example sets `stable-window` to 60s in the `config-autoscaler` ConfigMap, as well as specifying the `config-domain` ConfigMap:
+
+```yaml
+apiVersion: operator.knative.dev/v1alpha1
+kind: KnativeServing
+metadata:
+  name: knative-serving
+  namespace: knative-serving
+spec:
+  config:
+    domain:
+      example.org: |
+        selector:
+          app: prod
+      example.com: ""
+    autoscaler:
+      stable-window: "60s"
+```