Merge pull request #13597 from kalexand-rh/enterprise-4.0

4 not v4

Author: kalexand-rh

_topic_map.yml

@@ -79,8 +79,8 @@ Name: Release notes
 Dir: release_notes
 Distros: openshift-enterprise
 Topics:
-- Name: Comparing OpenShift Container Platform v3 and v4
-  File: comparing_v3_v4
+- Name: Comparing OpenShift Container Platform 3 and 4
+  File: comparing_3_4
 ---
 Name: Architecture
 Dir: architecture

modules/architecture-overview.adoc

@@ -7,16 +7,16 @@
 
 With {product-title} v4, the core story remains unchanged: {product-title} offers
 your developers a set of tools to evolve their applications under operational oversight
-and using Kubernetes to provide application infrastructure. The key change to v4 is
+and using Kubernetes to provide application infrastructure. The key change to {product-title}4 is
 that the infrastructure and its management are flexible, automated, and self-managing.
 
-A major difference between {product-title} v3 and v4 is that v4 uses Operators
+A major difference between {product-title} 3 and {product-title} 4 is that {product-title} 4 uses Operators
 as both the fundamental unit of the product and an option for easily deploying
 and managing utilities that your apps use.
 
-{product-title} v4 runs on top of a Kubernetes cluster, with data about the
-objects stored in etcd, a reliable clustered key-value store. The cluster is 
-enhanced with standard components that you need to run your cluster, including 
+{product-title} 4 runs on top of a Kubernetes cluster, with data about the
+objects stored in etcd, a reliable clustered key-value store. The cluster is
+enhanced with standard components that you need to run your cluster, including
 network, ingress, logging, and monitoring, that run as Operators to increase the
 ease and automation of installation, scaling, and maintenance.
 
@@ -43,7 +43,7 @@ report status or write back to the object.
 {product-title} offers a catalog of supporting application infrastructure that
 includes:
 
-* Operators, which expose APIs that automate the complete component lifecycle 
+* Operators, which expose APIs that automate the complete component lifecycle
 and include components like databases
 * Service bindings, which consume services that run outside the cluster
 * Templates, which are simple instant examples

modules/machine-api-overview.adoc

@@ -5,9 +5,9 @@
 [id='machine-api-overview-{context}']
 = Machine API overview
 
-For {product-title} v4 clusters, the Machine API performs all node
+For {product-title} 4 clusters, the Machine API performs all node
 management actions after the cluster installation finishes. Because of this
-system, {product-title} v4 offers an elastic, dynamic provisioning
+system, {product-title} 4 offers an elastic, dynamic provisioning
 method on top of public or private cloud infrastructure.
 
 The Machine API is a combination of primary resources that are based on the upstream
@@ -54,6 +54,6 @@ ScalingPolicy so you can scale up nodes but not scale them down.
 In {product-title} version 3.11, you could not roll out a multi-zone architecture easily because the cluster
 did not manage machine provisioning. It is easier in 4.0. Each `MachineSet` is scoped
 to a single zone, so the installation program sends out `MachineSets` across availability zones
-on your behalf. And then because your compute is dynamic, and in 
+on your behalf. And then because your compute is dynamic, and in
 the face of a zone failure, you always have a zone for when you need to rebalance
 your machines. The autoscaler provides best-effort balancing over the life of a cluster.

modules/operators-overview.adoc

@@ -5,7 +5,7 @@
 [id='operators-overview-{context}']
 = Operators in {product-title}
 
-{product-title} v4 uses different classes of Operators to perform cluster 
+{product-title} 4 uses different classes of Operators to perform cluster
 operations and run services on the cluster for your applications to use.
 
 [id='platform-operators-{context}']
@@ -28,7 +28,7 @@ In {product-title} v4, all control plane components are run and managed as
 applications on the infrastructure to ensure a uniform and consistent management
 experience. The control plane services run as static pods so they can
 manage normal workloads or processes the same way that they manage disaster
-recovery. Aside from the core control plane components, other services run as 
+recovery. Aside from the core control plane components, other services run as
 normal pods on the cluster, managed by regular Kubernetes constructs. Unlike in the past
 where the `kubelet` could be running as containerized or non-containerized, the `kubelet`
 always runs as a `systemd` process.

release_notes/comparing_v3_v4.adoc renamed to release_notes/comparing_3_4.adoc

@@ -1,11 +1,11 @@
 [id='architecture']
-= Comparing {product-title} v3 and v4
+= Comparing {product-title} 3 and 4
 include::modules/common-attributes.adoc[]
 :context: comparing_v3_v4
 toc::[]
 
 [IMPORTANT]
 ====
-This is a placeholder for the high-level information about {product-title} v4 that is
-new and different from v3. Final placement in the TOC TBD.
+This is a placeholder for the high-level information about {product-title} 4 that is
+new and different from {product-title} 3. Final placement in the TOC TBD.
 ====