<commit_before>
// Module included in the following assemblies:
//
// * assemblies/rosa-service-definition.adoc

[id="rosa-sdpolicy-account-management_{context}"]
= Account management


This section provides information about the service definition for {product-title} account management.

[id="rosa-sdpolicy-billing_{context}"]
== Billing

{product-title} is billed through Amazon Web Services (AWS) based on the usage of AWS components used by the service, such as load balancers, storage, EC2 instances, other components, and Red Hat subscriptions for the OpenShift service.

Any additional Red Hat software must be purchased separately.

[id="rosa-sdpolicy-cluster-self-service_{context}"]
== Cluster self-service

Customers can self-service their clusters, including, but not limited to:

* Create a cluster
* Delete a cluster
* Add or remove an identity provider
* Add or remove a user from an elevated group
* Configure cluster privacy
* Add or remove machine pools and configure autoscaling
* Define upgrade policies

These tasks can be self-serviced using the `rosa` CLI utility.

[id="rosa-sdpolicy-compute_{context}"]
== Compute

Single availability zone clusters require a minimum of 3 control planes, 2 infrastructure nodes, and 2 worker nodes deployed to a single availability zone.

Multiple availability zone clusters require a minimum of 3 control planes. 3 infrastructure nodes, and 3 worker nodes. Additional nodes must be purchased in multiples of three to maintain proper node distribution.

All {product-title} clusters support a maximum of 180 worker nodes.

[NOTE]
====
The `Default` machine pool node type and size cannot be changed after the cluster is created.
====

Control plane and infrastructure nodes are deployed and managed by Red Hat. Shutting down the underlying infrastructure through the cloud provider console is unsupported and can lead to data loss. 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. Control plane and infrastructure nodes are strictly for Red Hat workloads to operate the service, and customer workloads are not permitted to be deployed on these nodes.

[NOTE]
====
Approximately one vCPU core and 1 GiB of memory are reserved on each worker node and removed from allocatable resources. This reservation of resources is necessary to run processes required by the underlying platform. These processes include system daemons such as udev, kubelet, and container runtime among others. The reserved resources also account for kernel reservations.

{OCP} core systems such as audit log aggregation, metrics collection, DNS, image registry, SDN, and others might consume additional allocatable resources to maintain the stability and maintainability of the cluster. The additional resources consumed might vary based on usage.

For additional information, see the link:https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved[Kubernetes documentation].
====

[id="rosa-sdpolicy-aws-compute-types_{context}"]
== AWS compute types

{product-title} offers the following worker node types and sizes:

General purpose

- M5.xlarge (4 vCPU, 16 GiB)
- M5.2xlarge (8 vCPU, 32 GiB)
- M5.4xlarge (16 vCPU, 64 GiB)
- M5.8xlarge (32 vCPU, 128 GiB)
- M5.12xlarge (48 vCPU, 192 GiB)
- M5.16xlarge (64 vCPU, 256 GiB)
- M5.24xlarge (96 vCPU, 384 GiB)

Memory-optimized

- R5.xlarge (4 vCPU, 32 GiB)
- R5.2xlarge (8 vCPU, 64 GiB)
- R5.4xlarge (16 vCPU, 128 GiB)
- R5.8xlarge (32 vCPU, 256 GiB)
- R5.12xlarge (48 vCPU, 384 GiB)
- R5.16xlarge (64 vCPU, 512 GiB)
- R5.24xlarge (96 vCPU, 768 GiB)

Compute-optimized

- C5.2xlarge (8 vCPU, 16 GiB)
- C5.4xlarge (16 vCPU, 32 GiB)
- C5.9xlarge (36 vCPU, 72 GiB)
- C5.12xlarge (48 vCPU, 96 GiB)
- C5.18xlarge (72 vCPU, 144 GiB)
- C5.24xlarge (96 vCPU, 192 GiB)


[id="rosa-sdpolicy-regions-az_{context}"]
== Regions and availability zones
The following AWS regions are supported by Red Hat OpenShift 4 and are supported for {product-title}. Note: China and GovCloud (US) regions are not supported, regardless of their support on OpenShift 4.

- af-south-1 (Cape Town, AWS opt-in required)
- ap-east-1 (Hong Kong, AWS opt-in required)
- ap-northeast-1 (Tokyo)
- ap-northeast-2 (Seoul)
- ap-northeast-3 (Osaka)
- ap-south-1 (Mumbai)
- ap-southeast-1 (Singapore)
- ap-southeast-2 (Sydney)
- ca-central-1 (Central Canada)
- eu-central-1 (Frankfurt)
- eu-north-1 (Stockholm)
- eu-south-1 (Milan, AWS opt-in required)
- eu-west-1 (Ireland)
- eu-west-2 (London)
- eu-west-3 (Paris)
- me-south-1 (Bahrain, AWS opt-in required)
- sa-east-1 (São Paulo)
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-1 (N. California)
- us-west-2 (Oregon)

Multiple availability zone clusters can only be deployed in regions with at least 3 availability zones. For more information, see the link:https://aws.amazon.com/about-aws/global-infrastructure/regions_az/[Regions and Availability Zones] section in the AWS documentation.

Each new {product-title} cluster is installed within an installer-created or preexisting Virtual Private Cloud (VPC) in a single region, with the option to deploy into a single availability zone (Single-AZ) or across multiple availability zones (Multi-AZ). This provides cluster-level network and resource isolation, and enables cloud-provider VPC settings, such as VPN connections and VPC Peering. Persistent volumes (PVs) are backed by AWS Elastic Block Storage (EBS), and are specific to the availability zone in which they are provisioned. Persistent volume claims (PVCs) do not bind to a volume until the associated pod resource is assigned into a specific availability zone to prevent unschedulable pods. Availability zone-specific resources are only usable by resources in the same availability zone.

[WARNING]
====
The region and the choice of single or multiple availability zone cannot be changed after a cluster has been deployed.
====

[id="rosa-sdpolicy-sla_{context}"]
== Service Level Agreement (SLA)
Any SLAs for the service itself are defined in Appendix 4 of the link:https://www.redhat.com/licenses/Appendix_4_Red_Hat_Online_Services_20210503.pdf[Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services)].


[id="rosa-limited-support_{context}"]
== Limited support status

You must not remove or replace any native {product-title} components or any other component that is installed and managed by Red Hat. If using cluster administration rights, Red Hat is not responsible for any actions taken by you or any of your authorized users, including actions that might affect infrastructure services, service availability, and data loss.

If any actions that affect infrastructure services, service availability, or data loss are detected, Red Hat will notify the customer of such and request either that the action be reverted or to create a support case to work with Red Hat to remedy any issues.


[id="rosa-sdpolicy-support_{context}"]
== Support
{product-title} includes Red Hat Premium Support, which can be accessed by using the link:https://access.redhat.com/support?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[Red Hat Customer Portal].

See {product-title} link:https://access.redhat.com/support/offerings/openshift/sla?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[SLAs] for support response times.

AWS support is subject to a customer's existing support contract with AWS.
<commit_msg>OSDOCS-3421: Added a collapsible list to the ROSA documentation.<commit_after>
// Module included in the following assemblies:
//
// * assemblies/rosa-service-definition.adoc

[id="rosa-sdpolicy-account-management_{context}"]
= Account management


This section provides information about the service definition for {product-title} account management.

[id="rosa-sdpolicy-billing_{context}"]
== Billing

{product-title} is billed through Amazon Web Services (AWS) based on the usage of AWS components used by the service, such as load balancers, storage, EC2 instances, other components, and Red Hat subscriptions for the OpenShift service.

Any additional Red Hat software must be purchased separately.

[id="rosa-sdpolicy-cluster-self-service_{context}"]
== Cluster self-service

Customers can self-service their clusters, including, but not limited to:

* Create a cluster
* Delete a cluster
* Add or remove an identity provider
* Add or remove a user from an elevated group
* Configure cluster privacy
* Add or remove machine pools and configure autoscaling
* Define upgrade policies

These tasks can be self-serviced using the `rosa` CLI utility.

[id="rosa-sdpolicy-compute_{context}"]
== Compute

Single availability zone clusters require a minimum of 3 control planes, 2 infrastructure nodes, and 2 worker nodes deployed to a single availability zone.

Multiple availability zone clusters require a minimum of 3 control planes. 3 infrastructure nodes, and 3 worker nodes. Additional nodes must be purchased in multiples of three to maintain proper node distribution.

All {product-title} clusters support a maximum of 180 worker nodes.

[NOTE]
====
The `Default` machine pool node type and size cannot be changed after the cluster is created.
====

Control plane and infrastructure nodes are deployed and managed by Red Hat. Shutting down the underlying infrastructure through the cloud provider console is unsupported and can lead to data loss. 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. Control plane and infrastructure nodes are strictly for Red Hat workloads to operate the service, and customer workloads are not permitted to be deployed on these nodes.

[NOTE]
====
Approximately one vCPU core and 1 GiB of memory are reserved on each worker node and removed from allocatable resources. This reservation of resources is necessary to run processes required by the underlying platform. These processes include system daemons such as udev, kubelet, and container runtime among others. The reserved resources also account for kernel reservations.

{OCP} core systems such as audit log aggregation, metrics collection, DNS, image registry, SDN, and others might consume additional allocatable resources to maintain the stability and maintainability of the cluster. The additional resources consumed might vary based on usage.

For additional information, see the link:https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved[Kubernetes documentation].
====

[id="rosa-sdpolicy-aws-compute-types_{context}"]
== AWS compute types

{product-title} offers the following worker node types and sizes:

.General purpose compute types
[%collapsible]
====
- M5.xlarge (4 vCPU, 16 GiB)
- M5.2xlarge (8 vCPU, 32 GiB)
- M5.4xlarge (16 vCPU, 64 GiB)
- M5.8xlarge (32 vCPU, 128 GiB)
- M5.12xlarge (48 vCPU, 192 GiB)
- M5.16xlarge (64 vCPU, 256 GiB)
- M5.24xlarge (96 vCPU, 384 GiB)
====

.Memory-optimized compute types
[%collapsible]
====
- R5.xlarge (4 vCPU, 32 GiB)
- R5.2xlarge (8 vCPU, 64 GiB)
- R5.4xlarge (16 vCPU, 128 GiB)
- R5.8xlarge (32 vCPU, 256 GiB)
- R5.12xlarge (48 vCPU, 384 GiB)
- R5.16xlarge (64 vCPU, 512 GiB)
- R5.24xlarge (96 vCPU, 768 GiB)
====

.Compute-optimized compute types
[%collapsible]
====
- C5.2xlarge (8 vCPU, 16 GiB)
- C5.4xlarge (16 vCPU, 32 GiB)
- C5.9xlarge (36 vCPU, 72 GiB)
- C5.12xlarge (48 vCPU, 96 GiB)
- C5.18xlarge (72 vCPU, 144 GiB)
- C5.24xlarge (96 vCPU, 192 GiB)
====

[id="rosa-sdpolicy-regions-az_{context}"]
== Regions and availability zones
The following AWS regions are supported by Red Hat OpenShift 4 and are supported for {product-title}. Note: China and GovCloud (US) regions are not supported, regardless of their support on OpenShift 4.

- af-south-1 (Cape Town, AWS opt-in required)
- ap-east-1 (Hong Kong, AWS opt-in required)
- ap-northeast-1 (Tokyo)
- ap-northeast-2 (Seoul)
- ap-northeast-3 (Osaka)
- ap-south-1 (Mumbai)
- ap-southeast-1 (Singapore)
- ap-southeast-2 (Sydney)
- ca-central-1 (Central Canada)
- eu-central-1 (Frankfurt)
- eu-north-1 (Stockholm)
- eu-south-1 (Milan, AWS opt-in required)
- eu-west-1 (Ireland)
- eu-west-2 (London)
- eu-west-3 (Paris)
- me-south-1 (Bahrain, AWS opt-in required)
- sa-east-1 (São Paulo)
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-1 (N. California)
- us-west-2 (Oregon)

Multiple availability zone clusters can only be deployed in regions with at least 3 availability zones. For more information, see the link:https://aws.amazon.com/about-aws/global-infrastructure/regions_az/[Regions and Availability Zones] section in the AWS documentation.

Each new {product-title} cluster is installed within an installer-created or preexisting Virtual Private Cloud (VPC) in a single region, with the option to deploy into a single availability zone (Single-AZ) or across multiple availability zones (Multi-AZ). This provides cluster-level network and resource isolation, and enables cloud-provider VPC settings, such as VPN connections and VPC Peering. Persistent volumes (PVs) are backed by AWS Elastic Block Storage (EBS), and are specific to the availability zone in which they are provisioned. Persistent volume claims (PVCs) do not bind to a volume until the associated pod resource is assigned into a specific availability zone to prevent unschedulable pods. Availability zone-specific resources are only usable by resources in the same availability zone.

[WARNING]
====
The region and the choice of single or multiple availability zone cannot be changed after a cluster has been deployed.
====

[id="rosa-sdpolicy-sla_{context}"]
== Service Level Agreement (SLA)
Any SLAs for the service itself are defined in Appendix 4 of the link:https://www.redhat.com/licenses/Appendix_4_Red_Hat_Online_Services_20210503.pdf[Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services)].


[id="rosa-limited-support_{context}"]
== Limited support status

You must not remove or replace any native {product-title} components or any other component that is installed and managed by Red Hat. If using cluster administration rights, Red Hat is not responsible for any actions taken by you or any of your authorized users, including actions that might affect infrastructure services, service availability, and data loss.

If any actions that affect infrastructure services, service availability, or data loss are detected, Red Hat will notify the customer of such and request either that the action be reverted or to create a support case to work with Red Hat to remedy any issues.


[id="rosa-sdpolicy-support_{context}"]
== Support
{product-title} includes Red Hat Premium Support, which can be accessed by using the link:https://access.redhat.com/support?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[Red Hat Customer Portal].

See {product-title} link:https://access.redhat.com/support/offerings/openshift/sla?extIdCarryOver=true&sc_cid=701f2000001Css5AAC[SLAs] for support response times.

AWS support is subject to a customer's existing support contract with AWS.

{'fraction_non_alphanumeric': 0.0799657195596282, 'fraction_numerical': 0.02702880875469708, 'mean_word_length': 4.73101624480544, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 10, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7580345', 'n_tokens_mistral': 4560, 'n_tokens_neox': 4208, 'n_words': 1933}