standard-non-ccs

mletalie · mletalie · commit 75afb8507b69 · 2025-01-28T08:25:08.000-05:00
diff --git a/modules/sdpolicy-am-aws-compute-types-non-ccs.adoc b/modules/sdpolicy-am-aws-compute-types-non-ccs.adoc
@@ -3,7 +3,7 @@
 // * osd_architecture/osd_policy/osd-service-definition.adoc
 :_mod-docs-content-type: CONCEPT
 [id="aws-instance-types-non-ccs_{context}"]
-= AWS instance types for standard clusters
+= AWS instance types for non-CCS clusters
 
 {product-title} offers the following worker node types and sizes on AWS:
 
diff --git a/modules/sdpolicy-am-billing.adoc b/modules/sdpolicy-am-billing.adoc
@@ -39,10 +39,10 @@ Cloud provider for consumption of cloud infrastructure
 Customers that use their own cloud infrastructure account, referred to as Customer Cloud Subscription (CSS), are responsible to pre-purchase or provide Reserved Instance (RI) compute instances to ensure lower cloud infrastructure costs.
 ====
 
-Additional resources can be purchased for an OpenShift Dedicated Cluster, including:
+Additional resources can be purchased for an OpenShift Dedicated cluster, including:
 
 * Additional nodes (can be different types and sizes through the use of machine pools)
 * Middleware (JBoss EAP, JBoss Fuse, and so on) - additional pricing based on specific middleware component
-* Additional storage in increments of 500 GB (standard only; 100 GB included)
-* Additional 12 TiB Network I/O (standard only; 12 TB included)
-* Load Balancers for Services are available in bundles of 4; enables non-HTTP/SNI traffic or non-standard ports (standard only)
+* Additional storage in increments of 500 GB (non-CCS only; 100 GB included)
+* Additional 12 TiB Network I/O (non-CCS only; 12 TB included)
+* Load Balancers for Services are available in bundles of 4; enables non-HTTP/SNI traffic or non-standard ports (non-CCS only)
diff --git a/modules/sdpolicy-am-compute.adoc b/modules/sdpolicy-am-compute.adoc
@@ -5,16 +5,22 @@
 [id="instance-types_{context}"]
 = Instance types
 
-Single availability zone clusters require a minimum of 2 worker nodes for Customer Cloud Subscription (CCS) clusters deployed to a single availability zone. A minimum of 4 worker nodes is required for standard clusters. These 4 worker nodes are included in the base subscription.
+Single availability zone clusters require a minimum of 2 worker nodes for Customer Cloud Subscription (CCS) clusters deployed to a single availability zone. A minimum of 4 worker nodes is required for non-CCS clusters. These 4 worker nodes are included in the base subscription.
 
-Multiple availability zone clusters require a minimum of 3 worker nodes for Customer Cloud Subscription (CCS) clusters, 1 deployed to each of 3 availability zones. A minimum of 9 worker nodes are required for standard clusters. These 9 worker nodes are included in the base subscription, and additional nodes must be purchased in multiples of 3 to maintain proper node distribution.
+Multiple availability zone clusters require a minimum of 3 worker nodes for Customer Cloud Subscription (CCS) clusters, 1 deployed to each of 3 availability zones. A minimum of 9 worker nodes are required for non-CCS clusters. These 9 worker nodes are included in the base subscription, and additional nodes must be purchased in multiples of 3 to maintain proper node distribution.
 
 [NOTE]
 ====
 All worker nodes within a single {product-title} machine pool must be of the same type and size. However, worker nodes across multiple machine pools within an {product-title} cluster can be of different types and sizes.
 ====
 
-Control plane and infrastructure nodes are also provided by Red Hat. There are at least 3 control plane nodes that handle etcd and API-related workloads. There are at least 2 infrastructure nodes that handle metrics, routing, the web console, and other workloads. You must not run any workloads on the control plane and infrastructure nodes. Any workloads you intend to run must be deployed on worker nodes. See the Red Hat Operator support section below for more information about Red Hat workloads that must be deployed on worker nodes.
+Control plane and infrastructure nodes are deployed and managed by Red{nbsp}Hat. There are at least 3 control plane nodes that handle etcd and API-related workloads. There are at least 2 infrastructure nodes that handle metrics, routing, the web console, and other workloads. You must not run any workloads on the control plane and infrastructure nodes. Any workloads you intend to run must be deployed on worker nodes.
+[IMPORTANT]
+====
+Shutting down the underlying infrastructure through the cloud provider console is unsupported and can lead to data loss.
+====
+
+For more information about Red{nbsp}Hat workloads that must be deployed on worker nodes, see the _Red{nbsp}Hat Operator support_ section below.
 
 [NOTE]
 ====
diff --git a/modules/sdpolicy-networking.adoc b/modules/sdpolicy-networking.adoc
@@ -32,15 +32,15 @@ Custom domains and subdomains are not available for the platform service routes,
 {product-title} uses up to 5 different load balancers:
 
 * Internal control plane load balancer that is internal to the cluster and used to balance traffic for internal cluster communications.
-* External control plane load balancer that is used for accessing the {OCP} and Kubernetes APIs. This load balancer can be disabled in {cluster-manager-first}. If this load balancer is disabled, Red Hat reconfigures the API DNS to point to the internal control load balancer.
-* External control plane load balancer for Red Hat that is reserved for cluster management by Red Hat. Access is strictly controlled, and communication is only possible from allowlisted bastion hosts.
+* External control plane load balancer that is used for accessing the {OCP} and Kubernetes APIs. This load balancer can be disabled in {cluster-manager-first}. If this load balancer is disabled, Red{nbsp}Hat reconfigures the API DNS to point to the internal control load balancer.
+* External control plane load balancer for Red{nbsp}Hat that is reserved for cluster management by Red{nbsp}Hat. Access is strictly controlled, and communication is only possible from allowlisted bastion hosts.
 * Default router/ingress load balancer that is the default application load balancer, denoted by `apps` in the URL. The default load balancer can be configured in {cluster-manager} to be either publicly accessible over the internet, or only privately accessible over a pre-existing private connection. All application routes on the cluster are exposed on this default router load balancer, including cluster services such as the logging UI, metrics API, and registry.
 * Optional: Secondary router/ingress load balancer that is a secondary application load balancer, denoted by `apps2` in the URL. The secondary load balancer can be configured in {cluster-manager} to be either publicly accessible over the internet, or only privately accessible over a pre-existing private connection. If a 'Label match' is configured for this router load balancer, then only application routes matching this label will be exposed on this router load balancer, otherwise all application routes are also exposed on this router load balancer.
-* Optional: Load balancers for services that can be mapped to a service running on {product-title} to enable advanced ingress features, such as non-HTTP/SNI traffic or the use of non-standard ports. These can be purchased in groups of 4 for standard clusters, or they can be provisioned without charge in Customer Cloud Subscription (CCS) clusters; however, each AWS account has a quota that link:https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-limits.html[limits the number of Classic Load Balancers] that can be used within each cluster.
+* Optional: Load balancers for services that can be mapped to a service running on {product-title} to enable advanced ingress features, such as non-HTTP/SNI traffic or the use of non-standard ports. These can be purchased in groups of 4 for non-CCS clusters, or they can be provisioned through the cloud provider console in Customer Cloud Subscription (CCS) clusters; however, each AWS account has a quota that link:https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-limits.html[limits the number of Classic Load Balancers] that can be used within each cluster.
 
 [id="network-usage{context}"]
 == Network usage
-For standard {product-title} clusters, network usage is measured based on data transfer between inbound, VPC peering, VPN, and AZ traffic. On a standard {product-title} base cluster, 12 TB of network I/O is provided. Additional network I/O can be purchased in 12 TB increments. For CCS {product-title} clusters, network usage is not monitored, and is billed directly by the cloud provider.
+For non-CCS {product-title} clusters, network usage is measured based on data transfer between inbound, VPC peering, VPN, and AZ traffic. On a non-CCS {product-title} base cluster, 12 TB of network I/O is provided. Additional network I/O can be purchased in 12 TB increments. For CCS {product-title} clusters, network usage is not monitored, and is billed directly by the cloud provider.
 
 [id="cluster-ingress_{context}"]
 == Cluster ingress
@@ -79,7 +79,7 @@ $ oc run ip-lookup --image=busybox -i -t --restart=Never --rm -- /bin/sh -c "/bi
 
 [IMPORTANT]
 ====
-Red Hat SREs do not monitor private network connections. Monitoring these connections is the responsibility of the customer.
+Red{nbsp}Hat SREs do not monitor private network connections. Monitoring these connections is the responsibility of the customer.
 ====
 
 [id="dns-forwarding_{context}"]
diff --git a/modules/sdpolicy-storage.adoc b/modules/sdpolicy-storage.adoc
@@ -16,7 +16,7 @@ EBS volumes used for persistent volumes (PVs) are encrypted-at-rest by default.
 
 [id="block-storage_{context}"]
 == Block storage (RWO)
-Persistent volumes (PVs) are backed by AWS EBS and Google Cloud persistent disk block storage, which uses the ReadWriteOnce (RWO) access mode. On a standard {product-title} base cluster, 100 GB of block storage is provided for PVs, which is dynamically provisioned and recycled based on application requests. Additional persistent storage can be purchased in 500 GB increments.
+Persistent volumes (PVs) are backed by AWS EBS and Google Cloud persistent disk block storage, which uses the ReadWriteOnce (RWO) access mode. On a non-CCS {product-title} base cluster, 100 GB of block storage is provided for PVs, which is dynamically provisioned and recycled based on application requests. Additional persistent storage can be purchased in 500 GB increments.
 
 PVs can only be attached to a single node at a time and are specific to the availability zone in which they were provisioned, but they can be attached to any node in the availability zone.
 
@@ -25,4 +25,4 @@ Each cloud provider has its own limits for how many PVs can be attached to a sin
 [id="shared-storage_{context}"]
 == Shared storage (RWX)
 
-The AWS CSI Driver can be used to provide RWX support for {product-title} on AWS. A community Operator is provided to simplify setup. See link:https://access.redhat.com/articles/5025181[AWS EFS Setup for OpenShift Dedicated and Red Hat OpenShift Service on AWS] for details. 
+The AWS CSI Driver can be used to provide RWX support for {product-title} on AWS. A community Operator is provided to simplify setup. For more information, see link:https://access.redhat.com/articles/5025181[AWS EFS Setup for OpenShift Dedicated and Red Hat OpenShift Service on AWS].
