Merge pull request #28035 from adellape/op_ref_api

adellape · web-flow · commit 5ff6e00c437c · 2020-12-10T15:31:10.000-07:00
Update "Red Hat Operators reference" modules for API object &amp; unwrap changes
diff --git a/modules/cloud-credential-operator.adoc b/modules/cloud-credential-operator.adoc
diff --git a/modules/cluster-authentication-operator.adoc b/modules/cluster-authentication-operator.adoc
@@ -8,8 +8,7 @@
 [discrete]
 == Purpose
 
-The Cluster Authentication Operator installs and maintains the Authentication
-Custom Resource in a cluster and can be viewed with:
+The Cluster Authentication Operator installs and maintains the `Authentication` custom resource in a cluster and can be viewed with:
 
 [source,terminal]
 ----
diff --git a/modules/cluster-autoscaler-operator.adoc b/modules/cluster-autoscaler-operator.adoc
@@ -8,8 +8,7 @@
 [discrete]
 == Purpose
 
-The Cluster Autoscaler Operator manages deployments of the OpenShift Cluster
-Autoscaler using the cluster-api provider.
+The Cluster Autoscaler Operator manages deployments of the OpenShift Cluster Autoscaler using the `cluster-api` provider.
 
 [discrete]
 == Project
@@ -19,10 +18,5 @@ link:https://github.com/openshift/cluster-autoscaler-operator[cluster-autoscaler
 [discrete]
 == CRDs
 
-* `ClusterAutoscaler`: This is a singleton resource, which controls the configuration
-of the cluster's autoscaler instance. The Operator will only respond to the
-`ClusterAutoscaler` resource named `default` in the managed namespace, the
-value of the `WATCH_NAMESPACE` environment variable.
-* `MachineAutoscaler`: This resource targets a node group and manages the
-annotations to enable and configure autoscaling for that group, the `min` and
-`max` size. Currently only `MachineSet` objects can be targeted.
+* `ClusterAutoscaler`: This is a singleton resource, which controls the configuration autoscaler instance for the cluster. The Operator only responds to the `ClusterAutoscaler` resource named `default` in the managed namespace, the value of the `WATCH_NAMESPACE` environment variable.
+* `MachineAutoscaler`: This resource targets a node group and manages the annotations to enable and configure autoscaling for that group, the `min` and `max` size. Currently only `MachineSet` objects can be targeted.
diff --git a/modules/cluster-dns-operator.adoc b/modules/cluster-dns-operator.adoc
@@ -8,17 +8,14 @@
 [discrete]
 == Purpose
 
-The DNS Operator deploys and manages CoreDNS to provide a name resolution
-service to pods that enables DNS-based Kubernetes Service discovery in
-{product-title}.
+The DNS Operator deploys and manages CoreDNS to provide a name resolution service to pods that enables DNS-based Kubernetes Service discovery in {product-title}.
 
 The Operator creates a working default deployment based on the cluster's configuration.
 
 * The default cluster domain is `cluster.local`.
 * Configuration of the CoreDNS Corefile or Kubernetes plug-in is not yet supported.
 
-The DNS Operator manages CoreDNS as a Kubernetes daemon set exposed as a service
-with a static IP. CoreDNS runs on all nodes in the cluster.
+The DNS Operator manages CoreDNS as a Kubernetes daemon set exposed as a service with a static IP. CoreDNS runs on all nodes in the cluster.
 
 [discrete]
 == Project
diff --git a/modules/cluster-image-registry-operator.adoc b/modules/cluster-image-registry-operator.adoc
@@ -8,21 +8,13 @@
 [discrete]
 == Purpose
 
-The Cluster Image Registry Operator manages a singleton instance of the
-{product-title} registry. It manages all configuration of the registry,
-including creating storage.
+The Cluster Image Registry Operator manages a singleton instance of the {product-title} registry. It manages all configuration of the registry, including creating storage.
 
-On initial start up, the Operator creates a default `image-registry` resource
-instance based on the configuration detected in the cluster. This indicates
-what cloud storage type to use based on the cloud provider.
+On initial start up, the Operator creates a default `image-registry` resource instance based on the configuration detected in the cluster. This indicates what cloud storage type to use based on the cloud provider.
 
-If insufficient information is available to define a complete `image-registry`
-resource, then an incomplete resource is defined and the Operator updates the
-resource status with information about what is missing.
+If insufficient information is available to define a complete `image-registry` resource, then an incomplete resource is defined and the Operator updates the resource status with information about what is missing.
 
-The Cluster Image Registry Operator runs in the `openshift-image-registry`
-namespace and it also manages the registry instance in that location. All
-configuration and workload resources for the registry reside in that namespace.
+The Cluster Image Registry Operator runs in the `openshift-image-registry` namespace and it also manages the registry instance in that location. All configuration and workload resources for the registry reside in that namespace.
 
 [discrete]
 == Project
diff --git a/modules/cluster-kube-scheduler-operator.adoc b/modules/cluster-kube-scheduler-operator.adoc
@@ -8,9 +8,7 @@
 [discrete]
 == Purpose
 
-The Kubernetes Scheduler Operator manages and updates the Kubernetes Scheduler
-deployed on top of {product-title}. The operator is based on the {product-title} library-go
-framework and it is installed with the Cluster Version Operator (CVO).
+The Kubernetes Scheduler Operator manages and updates the Kubernetes Scheduler deployed on top of {product-title}. The Operator is based on the {product-title} `library-go` framework and it is installed with the Cluster Version Operator (CVO).
 
 The Kubernetes Scheduler Operator contains the following components:
 
@@ -34,5 +32,4 @@ The configuration for the Kubernetes Scheduler is the result of merging:
 * a default configuration.
 * an observed configuration from the spec `schedulers.config.openshift.io`.
 
-All of these are sparse configurations, invalidated JSON snippets which are
-merged in order to form a valid configuration at the end.
+All of these are sparse configurations, invalidated JSON snippets which are merged in order to form a valid configuration at the end.
diff --git a/modules/cluster-monitoring-operator.adoc b/modules/cluster-monitoring-operator.adoc
@@ -8,8 +8,7 @@
 [discrete]
 == Purpose
 
-The Cluster Monitoring Operator manages and updates the Prometheus-based cluster
-monitoring stack deployed on top of {product-title}.
+The Cluster Monitoring Operator manages and updates the Prometheus-based cluster monitoring stack deployed on top of {product-title}.
 
 [discrete]
 == Project
@@ -19,21 +18,21 @@ link:https://github.com/openshift/cluster-monitoring-operator[openshift-monitori
 [discrete]
 == CRDs
 
-* alertmanagers.monitoring.coreos.com
+* `alertmanagers.monitoring.coreos.com`
 ** Scope: Namespaced
-** CR: alertmanager
+** CR: `alertmanager`
 ** Validation: Yes
-* prometheuses.monitoring.coreos.com
+* `prometheuses.monitoring.coreos.com`
 ** Scope: Namespaced
-** CR: prometheus
+** CR: `prometheus`
 ** Validation: Yes
-* prometheusrules.monitoring.coreos.com
+* `prometheusrules.monitoring.coreos.com`
 ** Scope: Namespaced
-** CR: prometheusrule
+** CR: `prometheusrule`
 ** Validation: Yes
-* servicemonitors.monitoring.coreos.com
+* `servicemonitors.monitoring.coreos.com`
 ** Scope: Namespaced
-** CR: servicemonitor
+** CR: `servicemonitor`
 ** Validation: Yes
 
 [discrete]
diff --git a/modules/cluster-network-operator.adoc b/modules/cluster-network-operator.adoc
@@ -8,5 +8,4 @@
 [discrete]
 == Purpose
 
-The Cluster Network Operator installs and upgrades the networking components on
-an OpenShift Kubernetes cluster.
+The Cluster Network Operator installs and upgrades the networking components on an {product-title} cluster.
diff --git a/modules/cluster-openshift-controller-manager-operators.adoc b/modules/cluster-openshift-controller-manager-operators.adoc
@@ -8,15 +8,14 @@
 [discrete]
 == Purpose
 
-The OpenShift Controller Manager Operator installs and maintains the `OpenShiftControllerManager` Custom Resource in a cluster and can be viewed with:
+The OpenShift Controller Manager Operator installs and maintains the `OpenShiftControllerManager` custom resource in a cluster and can be viewed with:
 
 [source,terminal]
 ----
 $ oc get clusteroperator openshift-controller-manager -o yaml
 ----
 
-The Custom Resource Definition `openshiftcontrollermanagers.operator.openshift.io`
-can be viewed in a cluster with:
+The custom resource definitino (CRD) `openshiftcontrollermanagers.operator.openshift.io` can be viewed in a cluster with:
 
 [source,terminal]
 ----
diff --git a/modules/cluster-samples-operator.adoc b/modules/cluster-samples-operator.adoc
@@ -8,20 +8,21 @@
 [discrete]
 == Purpose
 
-The Cluster Samples Operator manages the sample imagestreams and templates stored in the `openshift` namespace.
+The Cluster Samples Operator manages the sample image streams and templates stored in the `openshift` namespace.
 
-On initial start up, the Operator creates the default samples configuration resource to initiate the creation of the imagestreams and templates. The configuration object
-is a cluster scoped object with the key `cluster` and type `configs.samples`.
+On initial start up, the Operator creates the default samples configuration resource to initiate the creation of the image streams and templates. The configuration object is a cluster scoped object with the key `cluster` and type `configs.samples`.
 
-The imagestreams are the {op-system-first}-based {product-title} imagestreams pointing to images on `registry.redhat.io`. Similarly, the templates are those categorized as {product-title} templates.
+The image streams are the {op-system-first}-based {product-title} image streams pointing to images on `registry.redhat.io`. Similarly, the templates are those categorized as {product-title} templates.
 
-The Cluster Samples Operator deployment is contained within the `openshift-cluster-samples-operator` namespace. On start up, the install pull secret is used by the imagestream import logic in the internal registry and API server to authenticate with `registry.redhat.io`. An administrator can create any additional secrets in the `openshift` namespace if they change the registry used for the sample imagestreams. If created, those secrets contain the content of a Docker `config.json` needed to facilitate image import.
+The Cluster Samples Operator deployment is contained within the `openshift-cluster-samples-operator` namespace. On start up, the install pull secret is used by the image stream import logic in the internal registry and API server to authenticate with `registry.redhat.io`. An administrator can create any additional secrets in the `openshift` namespace if they change the registry used for the sample image streams. If created, those secrets contain the content of a `config.json` for `docker` needed to facilitate image import.
 
-The image for the Cluster Samples Operator contains imagestream and template definitions for the associated {product-title} release. After the Cluster Samples Operator creates a sample, it adds an annotation that denotes the {product-title} version that it is compatible with. The Operator uses this annotation to ensure that each sample matches it's release version. Samples outside of its inventory are ignored, as are skipped samples. Modifications to any samples that are managed by the Operator are allowed as long as the version annotation is not modified or deleted.  However, on an upgrade, as the version annotation will change, those modifications can get replaced as the sample will be updated with the newer version. The Jenkins images are part of the image payload from the installation and are tagged into the imagestreams directly.
+The image for the Cluster Samples Operator contains image stream and template definitions for the associated {product-title} release. After the Cluster Samples Operator creates a sample, it adds an annotation that denotes the {product-title} version that it is compatible with. The Operator uses this annotation to ensure that each sample matches the compatible release version. Samples outside of its inventory are ignored, as are skipped samples.
+
+Modifications to any samples that are managed by the Operator are allowed as long as the version annotation is not modified or deleted. However, on an upgrade, as the version annotation will change, those modifications can get replaced as the sample will be updated with the newer version. The Jenkins images are part of the image payload from the installation and are tagged into the image streams directly.
 
 The samples resource includes a finalizer, which cleans up the following upon its deletion:
 
-* Operator-managed imagestreams
+* Operator-managed image streams
 * Operator-managed templates
 * Operator-generated configuration resources
 * Cluster status resources
diff --git a/modules/cluster-storage-operator.adoc b/modules/cluster-storage-operator.adoc
@@ -8,8 +8,7 @@
 [discrete]
 == Purpose
 
-The Cluster Storage Operator sets {product-title} cluster-wide storage defaults.
-It ensures a default storage class exists for {product-title} clusters.
+The Cluster Storage Operator sets {product-title} cluster-wide storage defaults. It ensures a default storage class exists for {product-title} clusters.
 
 [discrete]
 == Project
@@ -25,5 +24,4 @@ No configuration is required.
 == Notes
 
 * The Cluster Storage Operator supports Amazon Web Services (AWS) and {rh-openstack-first}.
-* The created storage class can be made non-default by editing its annotation, but
-the storage class cannot be deleted as long as the Operator runs.
+* The created storage class can be made non-default by editing its annotation, but the storage class cannot be deleted as long as the Operator runs.
diff --git a/modules/etcd-operator.adoc b/modules/etcd-operator.adoc
@@ -9,7 +9,6 @@
 == Purpose
 
 The etcd cluster Operator automates etcd cluster scaling, enables etcd monitoring and metrics, and simplifies disaster recovery procedures.
-
 [discrete]
 == Project
 
@@ -18,14 +17,15 @@ link:https://github.com/openshift/cluster-etcd-operator/[cluster-etcd-operator]
 [discrete]
 == CRDs
 
-* etcds.operator.openshift.io
+* `etcds.operator.openshift.io`
 ** Scope: Cluster
-** CR: etcd
+** CR: `etcd`
 ** Validation: Yes
 
 [discrete]
 == Configuration objects
 
+[source,terminal]
 ----
 $ oc edit etcd cluster
 ----
diff --git a/modules/ingress-operator.adoc b/modules/ingress-operator.adoc
@@ -18,17 +18,17 @@ link:https://github.com/openshift/cluster-ingress-operator[openshift-ingress-ope
 [discrete]
 == CRDs
 
-* clusteringresses.ingress.openshift.io
+* `clusteringresses.ingress.openshift.io`
 ** Scope: Namespaced
-** CR: clusteringresses
+** CR: `clusteringresses`
 ** Validation: No
 
 [discrete]
 == Configuration objects
 
 * Cluster config
-** Type Name: clusteringresses.ingress.openshift.io
-** Instance Name: default
+** Type Name: `clusteringresses.ingress.openshift.io`
+** Instance Name: `default`
 ** View Command:
 +
 [source,terminal]
@@ -39,21 +39,16 @@ $ oc get clusteringresses.ingress.openshift.io -n openshift-ingress-operator def
 [discrete]
 == Notes
 
-The Ingress Operator sets up the router in the `openshift-ingress` project and
-creates the deployment for the router:
+The Ingress Operator sets up the router in the `openshift-ingress` project and creates the deployment for the router:
 
 [source,terminal]
 ----
 $ oc get deployment -n openshift-ingress
 ----
 
-The Ingress Operator uses the `clusterNetwork[].cidr` from the network/cluster
-status to determine what mode (IPv4, IPv6, or dual stack) the managed ingress
-controller (router) should operate in. For example, if `clusterNetwork` contains
-only a v6 `cidr`, then the ingress controller will operate in v6-only mode. In
-the following example, ingress controllers managed by the Ingress Operator will
-run in v4-only mode because only one cluster network exists and the network is a
-v4 `cidr`:
+The Ingress Operator uses the `clusterNetwork[].cidr` from the `network/cluster` status to determine what mode (IPv4, IPv6, or dual stack) the managed ingress controller (router) should operate in. For example, if `clusterNetwork` contains only a v6 `cidr`, then the ingress controller operate in IPv6-only mode.
+
+In the following example, ingress controllers managed by the Ingress Operator will run in IPv4-only mode because only one cluster network exists and the network is an IPv4 `cidr`:
 
 [source,terminal]
 ----
diff --git a/modules/kube-apiserver-operator.adoc b/modules/kube-apiserver-operator.adoc
@@ -8,10 +8,7 @@
 [discrete]
 == Purpose
 
-The Kubernetes API Server Operator manages and updates the Kubernetes API server
-deployed on top of {product-title}. The Operator is based on the OpenShift
-library-go framework and it is installed using the Cluster Version Operator
-(CVO).
+The Kubernetes API Server Operator manages and updates the Kubernetes API server deployed on top of {product-title}. The Operator is based on the OpenShift library-go framework and it is installed using the Cluster Version Operator (CVO).
 
 [discrete]
 == Project
@@ -21,9 +18,9 @@ link:https://github.com/openshift/cluster-kube-apiserver-operator[openshift-kube
 [discrete]
 == CRDs
 
-* kubeapiservers.operator.openshift.io
+* `kubeapiservers.operator.openshift.io`
 ** Scope: Cluser
-** CR: kubeapiserver
+** CR: `kubeapiserver`
 ** Validation: Yes
 
 [discrete]
diff --git a/modules/kube-controller-manager-operator.adoc b/modules/kube-controller-manager-operator.adoc
@@ -8,10 +8,7 @@
 [discrete]
 == Purpose
 
-The Kubernetes Controller Manager Operator manages and updates the Kubernetes
-Controller Manager deployed on top of {product-title}. The Operator is based on
-OpenShift library-go framework and it is installed via the Cluster Version
-Operator (CVO).
+The Kubernetes Controller Manager Operator manages and updates the Kubernetes Controller Manager deployed on top of {product-title}. The Operator is based on OpenShift `library-go` framework and it is installed via the Cluster Version Operator (CVO).
 
 It contains the following components:
 
@@ -20,7 +17,7 @@ It contains the following components:
 * Installer based on static pods
 * Configuration observer
 
-By default, the Operator exposes Prometheus metrics through the metrics service.
+By default, the Operator exposes Prometheus metrics through the `metrics` service.
 
 [discrete]
 == Project
diff --git a/modules/machine-api-operator.adoc b/modules/machine-api-operator.adoc
@@ -8,8 +8,7 @@
 [discrete]
 == Purpose
 
-The Machine API Operator manages the lifecycle of specific purpose CRDs,
-controllers, and RBAC objects that extend the Kubernetes API. This declares the desired state of machines in a cluster.
+The Machine API Operator manages the lifecycle of specific purpose custom resource definitions (CRD), controllers, and RBAC objects that extend the Kubernetes API. This declares the desired state of machines in a cluster.
 
 [discrete]
 == Project
diff --git a/modules/machine-config-operator.adoc b/modules/machine-config-operator.adoc
@@ -9,21 +9,14 @@
 [discrete]
 == Purpose
 
-The Machine Config Operator manages and applies configuration and updates of the
-base operating system and container runtime, including everything between the
-kernel and kubelet.
+The Machine Config Operator manages and applies configuration and updates of the base operating system and container runtime, including everything between the kernel and kubelet.
 
 There are four components:
 
-* machine-config-server: Provides Ignition configuration to new machines joining the cluster.
-* machine-config-controller: Coordinates the upgrade of machines to the desired
-configurations defined by a `MachineConfig` object. Options are provided to
-control the upgrade for sets of machines individually.
-* machine-config-daemon: Applies new machine configuration during update.
-Validates and verifies the machine's state to the requested machine
-configuration.
-* machine-config: Provides a complete source of machine configuration at
-installation, first start up, and updates for a machine.
+* `machine-config-server`: Provides Ignition configuration to new machines joining the cluster.
+* `machine-config-controller`: Coordinates the upgrade of machines to the desired configurations defined by a `MachineConfig` object. Options are provided to control the upgrade for sets of machines individually.
+* `machine-config-daemon`: Applies new machine configuration during update. Validates and verifies the state of the machine to the requested machine configuration.
+* `machine-config`: Provides a complete source of machine configuration at installation, first start up, and updates for a machine.
 
 [discrete]
 == Project
diff --git a/modules/node-tuning-operator.adoc b/modules/node-tuning-operator.adoc
diff --git a/modules/openshift-apiserver-operator.adoc b/modules/openshift-apiserver-operator.adoc
diff --git a/modules/operator-marketplace.adoc b/modules/operator-marketplace.adoc
diff --git a/modules/prometheus-operator.adoc b/modules/prometheus-operator.adoc
