osdocs326 install concept updates

modules/installation-overview.adoc

@@ -26,11 +26,34 @@ These two basic types of {product-title} clusters are frequently called
 installer-provisioned infrastructure clusters and user-provisioned
 infrastructure clusters.
 
+Both types of clusters have the following characteristics:
+
+* Highly available infrastructure with no single points of failure is available
+by default
+* Administrators maintain control over what updates are applied and when
+
 You use the same installation program to deploy both types of clusters. The main
 assets generated by the installation program are the Ignition config files for the
 bootstrap, master, and worker machines. With these three configurations and correctly
 configured infrastructure, you can start an {product-title} cluster.
 
+After installation, each cluster machine uses {op-system-first} as the operating
+system. {op-system} is the immutable container host version of
+Red Hat Enterprise Linux (RHEL) and features a RHEL kernel with SELinux enabled
+by default. It includes the `kubelet`, which is the Kubernetes node agent, and
+the CRI-O container runtime, which is optimized for Kubernetes.
+
+Every control plane machine in an {product-title} {product-version} cluster must
+use {op-system}, which includes a critical first-boot provisioning tool called
+CoreOS Ignition. This tool enables the cluster to configure the machines.
+Operating system updates are delivered as an Atomic OSTree repository that is
+embedded in a container image that is rolled out across the cluster by an
+Operator. Actual operating system changes are made in-place on each machine as
+an atomic operation by using rpm-ostree. Together, these technologies enable
+{product-title} to manage the operating system like it manages any other
+application on the cluster, via in-place upgrades that keep the entire platform
+up-to-date. These in-place updates can reduce the burden on operations teams.
+
 [id="available-platforms_{context}"]
 == Available platforms
 
@@ -48,7 +71,7 @@ user-provisioned infrastructure on the following platforms:
 == Installation process
 
 When you install an {product-title} cluster, you download the
-installer from link:https://cloud.openshift.com/clusters/install[the OpenShift start page].
+installation program from link:https://cloud.openshift.com/clusters/install[the OpenShift start page].
 This site manages:
 
 * REST API for accounts
@@ -63,25 +86,22 @@ installation program differs depending on your installation type.
 
 * For clusters with installer-provisioned infrastructure, you delegate the
 infrastructure bootstrapping and provisioning to the installation program
-instead of doing it yourself. Because you do not use the installation program to upgrade or
-update your cluster, if you do not customize your cluster, you run the
-installer only once. If you customize your cluster, you run the installation
-program to generate the required configuration files and then run it again to
-deploy your cluster.
+instead of doing it yourself. The installion program creates all of the
+networking, machines, and operating systems that are required to support the
+cluster.
 
 * If you provision and manage the infrastructure for your cluster, you must
 provide all of the cluster infrastructure and resources, including the
-bootstrap node. You must run the installation program to generate the required
-configuration files and then run the installation program again to deploy a cluster
-to your configured infrastructure.
+bootstrap node, networking, load balancing, storage, and individual cluster
+machines.
 
 You use three sets of files during installation: an installation configuration
 file, Kubernetes manifests, and Ignition config files for your machine types.
 
 [IMPORTANT]
 ====
 It is possible to modify Kubernetes and the Ignition config files that control
-the underlying {op-system-first} operating system during installation. However,
+the underlying {op-system} operating system during installation. However,
 no validation is available to confirm the suitability of any modifications that
 you make to these objects. If you modify these objects, you might render
 your cluster non-functional. Because of this risk, modifying Kubernetes and
@@ -145,12 +165,16 @@ installation program to generate the assets that you require to provision the
 cluster infrastructure, create the cluster infrastructure, and then deploy
 the cluster to the infrastructure that you provided.
 
-If you do not use infrastructure that the installer provisioned, you must manage
+If you do not use infrastructure that the installation program provisioned, you must manage
 and maintain the cluster resources yourself, including:
 
 * The control plane and compute machines that make up the cluster
 * Load balancers
 * Cluster networking, including the DNS records and required subnets
+* Storage for the cluster infrastructure and applications
+
+If your cluster uses user-provisioned infrastructure, you have the option of
+adding RHEL worker nodes to your cluster.
 
 [discrete]
 === Bootstrap process details

modules/installation-requirements-user-infra.adoc

@@ -27,7 +27,14 @@ on the three control plane machines. You can remove the bootstrap machine after
 you install the cluster.
 ====
 
-The bootstrap and control plane machines must use {op-system-first} as the operating system.
+[IMPORTANT]
+====
+To maintain high availability of your cluster, use separate physical hosts for
+these cluster machines.
+====
+
+The bootstrap and control plane machines must use {op-system-first} as the
+operating system.
 
 [id="network-connectivity_{context}"]
 == Network connectivity requirements