updates for BYO

Author: kalexand-rh

architecture/architecture.adoc

@@ -3,7 +3,7 @@
 // * n/a
 
 [id='architecture']
-= {product-title} Architecture
+= {product-title} architecture
 include::modules/common-attributes.adoc[]
 :context: architecture
 toc::[]

modules/cloud_installations.adoc

@@ -9,7 +9,7 @@
 [IMPORTANT]
 ====
 In version {product-version}, you can install {product-title} on only Amazon
-Web Services (AWS) or your own hosts.
+Web Services (AWS).
 ====
 
 You can install either a standard cluster or a customized cluster. With a

modules/installation-options.adoc

@@ -5,12 +5,17 @@
 [id='installation-options-{context}']
 = Installation options
 
-{product-title} offers two installation options: fully-managed infrastructure and bring your own
-infrastructure. In version 4.0, the fully-managed option allows you to install a
-cluster in Amazon Web Services (AWS) that runs on Red Hat CoreOS nodes. If you want to
+In {product-title} version 4.0, you can install only clusters that use fully-managed
+infrastructure in Amazon Web Services (AWS). These clusters use Red Hat CoreOS
+nodes as the operating system. Future versions of {product-title} will support
+clusters that run on more cloud providers or using your own infrastructure.
+
+////
+If you want to
 use any other cloud or install your cluster on-premise, use the bring your own
 infrastructure option to install your cluster on existing Red Hat Enterprise 
 Linux (RHEL) hosts.
+////
 
 The fully-managed option offers full-stack automation to:
 
@@ -19,13 +24,14 @@ The fully-managed option offers full-stack automation to:
 * Manage control plane
 * Manage nodes
 
+////
 With the bring your own infrastructure option, you have more responsibilities.
 You must provide the hosts and update RHEL on them. {product-title} provides:
 
 * Managed control plane
 * Ansible to manage kubelet and container runtime
+////
 
-
-With both installation types, installation and upgrade both use an Operator
+Installation and upgrade both use an Operator
 that constantly reconciles component versions as if it were any other Kubernetes
 controller.

modules/machine-api-overview.adoc

@@ -5,7 +5,7 @@
 [id='machine-api-overview-{context}']
 = Machine API overview
 
-On fully-managed {product-title} clusters, the Machine API performs all node
+On {product-title} version 4.0 clusters, the Machine API performs all node
 management actions after the cluster installation finishes. Because of this
 system, {product-title} version 4.0 offers an elastic, dynamic provisioning
 method.

modules/node-management.adoc

@@ -3,11 +3,11 @@
 // * architecture/architecture.adoc
 
 [id='node-management-{context}']
-= Node management in fully-managed {product-title}
+= Node management in {product-title}
 
-The fully-managed version of {product-title} version 4.0 integrates management of
+{product-title} version 4.0 integrates management of
 the container operating system and cluster management. Because the cluster manages
-both its updates and updates to RHCOS, {product-title} provides an opinionated
+both its updates and updates to Red Hat CoreOS, {product-title} provides an opinionated
 lifecycle management experience that simplifies the orchestration of upgrades.
 
 {product-title} employs three DaemonSets and controllers to simplify node management:

modules/operators-overview.adoc

@@ -37,7 +37,7 @@ always runs as a `systemd` process.
 [id='second-level-operators-{context}']
 == Second-level Operators in {product-title}
 
-The cluster version Operator, when we talk about payload manifests, is a
+The Cluster Version Operator, when we talk about payload manifests, is a
 second-level Operator, the Operators that actually manage {product-title} as if
 it were a native Kubernetes application. Second-level Operators are not a
 codified concept, but the namespace where your code exists, the service accounts
@@ -46,7 +46,7 @@ link:https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-
 and pull secret that drives the operation of the Operator, and the Operator deployment.
 
 Second-level Operators write out to a CRD resource called the ClusterOperator
-that allows the cluster version Operator to understand the progress of the
+that allows the Cluster Version Operator to understand the progress of the
 managed component's deployment.
 
 [id='OLM-operators-{context}']

modules/update-service-overview.adoc

@@ -6,14 +6,14 @@
 == The {product-title} update service
 
 The {product-title} update service is the hosted service that provides over the air updates to both 
-{product-title} and RHCOS. It provides a graph, or diagram that contain
+{product-title} and Red Hat CoreOS. It provides a graph, or diagram that contain
 _vertices_ and the _edges_ that connect them, of component Operators. The edges
 in the graph show which versions you can safely upgrade to, and the vertices
 vertices are update payloads that specify the intended state of the managed cluster components.
-The cluster versionOperator checks with the {product-title} update service and determines valid upgrades and upgrade paths
+The Cluster Version Operator checks with the {product-title} update service and determines valid upgrades and upgrade paths
 based on current component versions and information in the graph. If you
 configure it to do so, the {product-title} update service sends the release artifacts that it needs to
-perform the upgrade to your image registry, and the cluster version Operator
+perform the upgrade to your image registry, and the Cluster Version Operator
 upgrades your cluster. By accepting automatic updates, you can automatically
 keep your cluster up to date with the most recent compatible components.
 
@@ -27,11 +27,11 @@ is available.
 ////
 The interaction between the registry and the {product-title} update service is different during
 bootstrap and continuous update modes. When you bootstrap the initial
-infrastructure, the cluster version Operator finds 
+infrastructure, the Cluster Version Operator finds 
 the fully qualified image name for the shortname of the images that it needs to 
 apply to the server during installation. It looks at the image stream that it needs
 to apply and renders it to disk. It calls bootkube and waits for a temporary minimal control
-plane to come up and load the cluster version Operator.
+plane to come up and load the Cluster Version Operator.
 ////
 
 During continuous update mode, two controllers run. One continuously updates