diff --git a/_topic_maps/_topic_map_osd.yml b/_topic_maps/_topic_map_osd.yml index 350d9277cb..42bee02a20 100644 --- a/_topic_maps/_topic_map_osd.yml +++ b/_topic_maps/_topic_map_osd.yml @@ -38,8 +38,6 @@ Distros: openshift-dedicated Topics: - Name: Understanding OpenShift Dedicated File: osd-understanding -- Name: Architecture concepts - File: osd-architecture - Name: Policies and service definition Dir: osd_policy Distros: openshift-dedicated @@ -57,9 +55,26 @@ Topics: - Name: Update life cycle File: osd-life-cycle # Created a new assembly in ROSA/OSD. In OCP, the assembly is in a book that is not in ROSA/OSD -- Name: About admission plugins - File: osd-admission-plug-ins - Distros: openshift-dedicated +# - Name: About admission plugins +# File: osd-admission-plug-ins +# Distros: openshift-dedicated +--- +Name: Architecture +Dir: architecture +Distros: openshift-dedicated +Topics: +- Name: Architecture overview + File: index +- Name: Product architecture + File: architecture +- Name: Control plane architecture + File: control-plane +- Name: NVIDIA GPU architecture overview + File: nvidia-gpu-architecture-overview +- Name: Understanding OpenShift development + File: understanding-development +- Name: Admission plugins + File: admission-plug-ins --- #Name: Tutorials #Dir: cloud_experts_tutorials diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml index cf23622648..c418f7638c 100644 --- a/_topic_maps/_topic_map_rosa.yml +++ b/_topic_maps/_topic_map_rosa.yml @@ -47,14 +47,6 @@ Distros: openshift-rosa Topics: - Name: Understanding ROSA File: rosa-understanding -- Name: ROSA architecture - Dir: rosa_architecture_sub - Distros: openshift-rosa - Topics: - - Name: Architecture concepts - File: rosa-basic-architecture-concepts - - Name: Architecture models - File: rosa-architecture-models - Name: Policies and service definition Dir: rosa_policy_service_definition Distros: openshift-rosa @@ -76,9 +68,9 @@ Topics: - Name: SRE and service account access File: rosa-sre-access # Created a new assembly in ROSA/OSD. In OCP, the assembly is in a book that is not in ROSA/OSD -- Name: About admission plugins - File: rosa-admission-plug-ins - Distros: openshift-rosa +# - Name: About admission plugins +# File: rosa-admission-plug-ins +# Distros: openshift-rosa - Name: About IAM resources for ROSA with STS File: rosa-sts-about-iam-resources - Name: OpenID Connect Overview @@ -86,6 +78,25 @@ Topics: # - Name: Training for ROSA # File: rosa-training --- +Name: Architecture +Dir: architecture +Distros: openshift-rosa +Topics: +- Name: Architecture overview + File: index +- Name: Product architecture + File: architecture +- Name: Architecture models + File: rosa-architecture-models +- Name: Control plane architecture + File: control-plane +- Name: NVIDIA GPU architecture overview + File: nvidia-gpu-architecture-overview +- Name: Understanding OpenShift development + File: understanding-development +- Name: Admission plugins + File: admission-plug-ins +--- Name: Tutorials Dir: cloud_experts_tutorials Distros: openshift-rosa diff --git a/osd_architecture/osd-architecture.adoc b/_unused_topics/osd-architecture.adoc similarity index 88% rename from osd_architecture/osd-architecture.adoc rename to _unused_topics/osd-architecture.adoc index bd16c89f35..301b58c0ff 100644 --- a/osd_architecture/osd-architecture.adoc +++ b/_unused_topics/osd-architecture.adoc @@ -12,4 +12,4 @@ include::modules/kubernetes-about.adoc[leveloffset=+1] include::modules/container-benefits.adoc[leveloffset=+1] -include::modules/osd-vs-ocp.adoc[leveloffset=+1] +include::modules/sd-vs-ocp.adoc[leveloffset=+1] diff --git a/rosa_architecture/rosa_architecture_sub/rosa-basic-architecture-concepts.adoc b/_unused_topics/rosa-basic-architecture-concepts.adoc similarity index 100% rename from rosa_architecture/rosa_architecture_sub/rosa-basic-architecture-concepts.adoc rename to _unused_topics/rosa-basic-architecture-concepts.adoc diff --git a/architecture/admission-plug-ins.adoc b/architecture/admission-plug-ins.adoc index 417c58ef7d..050997c658 100644 --- a/architecture/admission-plug-ins.adoc +++ b/architecture/admission-plug-ins.adoc @@ -6,8 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] -// Sentence taken from Architecture -> Index. -Admission plugins are used to help regulate how {product-title} functions. +Admission plugins are used to help regulate how {product-title} functions. // Concept modules include::modules/admission-plug-ins-about.adoc[leveloffset=+1] @@ -18,17 +17,20 @@ include::modules/admission-webhooks-about.adoc[leveloffset=+1] include::modules/admission-webhook-types.adoc[leveloffset=+1] +// user (groups=["dedicated-admins" "system:authenticated:oauth" "system:authenticated"]) is attempting to grant RBAC permissions not currently held, clusterroles.rbac.authorization.k8s.io "system:openshift:online:my-webhook-server" not found, cannot get resource "rolebindings", cannot create resource "apiservices", cannot create resource "validatingwebhookconfigurations" +ifndef::openshift-rosa,openshift-dedicated[] // Procedure module include::modules/configuring-dynamic-admission.adoc[leveloffset=+1] +endif::openshift-rosa,openshift-dedicated[] [role="_additional-resources"] [id="admission-plug-ins-additional-resources"] == Additional resources -ifdef::openshift-enterprise,openshift-webscale[] -* xref:../networking/hardware_networks/configuring-sriov-operator.adoc#configuring-sriov-operator[Limiting custom network resources managed by the SR-IOV network device plugin] -endif::[] +ifndef::openshift-rosa,openshift-dedicated[] +* xref:../networking/hardware_networks/configuring-sriov-operator.adoc#configuring-sriov-operator[Configuring the SR-IOV Network Operator] +endif::openshift-rosa,openshift-dedicated[] -* xref:../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations_dedicating_nodes-scheduler-taints-tolerations[Defining tolerations that enable taints to qualify which pods should be scheduled on a node] +* xref:../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations_dedicating_nodes-scheduler-taints-tolerations[Controlling pod placement using node taints] -* xref:../nodes/pods/nodes-pods-priority.adoc#admin-guide-priority-preemption-names_nodes-pods-priority[Pod priority class validation] +* xref:../nodes/pods/nodes-pods-priority.adoc#admin-guide-priority-preemption-names_nodes-pods-priority[Pod priority names] diff --git a/architecture/architecture.adoc b/architecture/architecture.adoc index 711cf3f4c1..1f1426cb95 100644 --- a/architecture/architecture.adoc +++ b/architecture/architecture.adoc @@ -35,4 +35,6 @@ retains a history of the images that have been referenced, and allows notification when an image is updated with a new version. //// +ifndef::openshift-dedicated,openshift-rosa[] include::modules/cluster-entitlements.adoc[leveloffset=+2] +endif::openshift-dedicated,openshift-rosa[] diff --git a/architecture/control-plane.adoc b/architecture/control-plane.adoc index 2c2b64e0d4..3e95b836eb 100644 --- a/architecture/control-plane.adoc +++ b/architecture/control-plane.adoc @@ -12,7 +12,15 @@ include::modules/architecture-machine-config-pools.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources -* xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection]. +ifndef::openshift-dedicated,openshift-rosa[] +* xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection] +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-rosa[] +* xref:../rosa_cluster_admin/rosa_nodes/rosa-nodes-machinepools-about.adoc#machine-pools[Machine pools] +endif::openshift-rosa[] +ifdef::openshift-dedicated[] +* xref:../osd_cluster_admin/osd_nodes/osd-nodes-machinepools-about.adoc#machine-pools[Machine pools] +endif::openshift-dedicated[] include::modules/architecture-machine-roles.adoc[leveloffset=+1] @@ -46,19 +54,26 @@ endif::[] include::modules/understanding-machine-config-operator.adoc[leveloffset=+1] +// These additional resources do not apply to OSD/ROSA +ifndef::openshift-dedicated,openshift-rosa[] [role="_additional-resources"] .Additional resources * For more information about detecting configuration drift, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection]. * For information about preventing the control plane machines from rebooting after the Machine Config Operator makes changes to the machine configuration, see xref:../support/troubleshooting/troubleshooting-operator-issues.adoc#troubleshooting-disabling-autoreboot-mco_troubleshooting-operator-issues[Disabling Machine Config Operator from automatically rebooting]. +endif::openshift-dedicated,openshift-rosa[] include::modules/etcd-overview.adoc[leveloffset=+1] +// These xrefs do not apply to OSD/ROSA +ifndef::openshift-dedicated,openshift-rosa[] [role="_additional-resources"] .Additional resources * xref:../scalability_and_performance/recommended-performance-scale-practices/recommended-etcd-practices.adoc#recommended-etcd-practices[Recommended etcd practices] * xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backing-up-etcd[Backing up etcd] +endif::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa[] include::modules/hosted-control-planes-overview.adoc[leveloffset=+1] [role="_additional-resources"] @@ -67,3 +82,4 @@ include::modules/hosted-control-planes-overview.adoc[leveloffset=+1] include::modules/hosted-control-planes-concepts-personas.adoc[leveloffset=+2] include::modules/hosted-control-planes-version-support.adoc[leveloffset=+2] +endif::openshift-dedicated,openshift-rosa[] diff --git a/architecture/index.adoc b/architecture/index.adoc index 3fce1f22d0..bdf5acc911 100644 --- a/architecture/index.adoc +++ b/architecture/index.adoc @@ -2,6 +2,9 @@ [id="architecture-overview"] = Architecture overview include::_attributes/common-attributes.adoc[] +ifdef::openshift-dedicated,openshift-rosa[] +include::_attributes/attributes-openshift-dedicated.adoc[] +endif::openshift-dedicated,openshift-rosa[] :context: architecture-overview toc::[] @@ -15,13 +18,24 @@ include::modules/openshift-architecture-common-terms.adoc[leveloffset=+1] [role="_additional-resources"] .Additional resources +// Topic not included in the OSD/ROSA docs +ifndef::openshift-dedicated,openshift-rosa[] * For more information on networking, see xref:../networking/understanding-networking.adoc#understanding-networking[{product-title} networking]. +endif::openshift-dedicated,openshift-rosa[] * For more information on storage, see xref:../storage/index.adoc#index[{product-title} storage]. * For more information on authentication, see xref:../authentication/index.adoc#index[{product-title} authentication]. * For more information on Operator Lifecycle Manager (OLM), see xref:../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[OLM]. * For more information on logging, see xref:../logging/cluster-logging.adoc#cluster-logging[About Logging]. +// Topic not included in the OSD/ROSA docs +ifndef::openshift-dedicated,openshift-rosa[] * For more information on over-the-air (OTA) updates, see xref:../updating/understanding_updates/intro-to-updates.adoc#understanding-openshift-updates[Introduction to OpenShift updates]. +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +include::modules/sd-vs-ocp.adoc[leveloffset=+1] +endif::openshift-dedicated,openshift-rosa[] + +ifndef::openshift-dedicated,openshift-rosa[] [id="about-installation-and-updates"] == About installation and updates @@ -29,6 +43,7 @@ As a cluster administrator, you can use the {product-title} xref:../architecture * Installer-provisioned infrastructure * User-provisioned infrastructure +endif::openshift-dedicated,openshift-rosa[] [id="about-control-planes"] == About the control plane @@ -60,6 +75,7 @@ Kubernetes works on basic units called pods. A pod is a single instance of a run You can create a service by grouping a set of pods and their access policies. Services provide permanent internal IP addresses and host names for other applications to use as pods are created and destroyed. Kubernetes defines workloads based on the type of your application. +ifndef::openshift-dedicated,openshift-rosa[] [id="coreos-and-ignition"] == About {op-system-first} and Ignition @@ -76,8 +92,8 @@ The {product-title} installation program creates the Ignition configuration file During the first boot, Ignition reads its configuration from the installation media or the location that you specify and applies the configuration to the machines. You can learn how xref:../architecture/architecture-rhcos.adoc#architecture-rhcos[Ignition works], the process for a {op-system-first} machine in an {product-title} cluster, view Ignition configuration files, and change Ignition configuration after an installation. +endif::openshift-dedicated,openshift-rosa[] [id="about-admission-plug-ins"] == About admission plugins -You can use xref:../architecture/admission-plug-ins.adoc#admission-plug-ins[admission plugins] to regulate how {product-title} functions. After a resource request is authenticated and authorized, admission plugins intercept the resource request to the master API to validate resource requests and to ensure that scaling policies are adhered to. -Admission plugins are used to enforce security policies, resource limitations, or configuration requirements. +You can use xref:../architecture/admission-plug-ins.adoc#admission-plug-ins[admission plugins] to regulate how {product-title} functions. After a resource request is authenticated and authorized, admission plugins intercept the resource request to the master API to validate resource requests and to ensure that scaling policies are adhered to. Admission plugins are used to enforce security policies, resource limitations, configuration requirements, and other settings. diff --git a/architecture/nvidia-gpu-architecture-overview.adoc b/architecture/nvidia-gpu-architecture-overview.adoc index 181dc0c6b7..11d53f8200 100644 --- a/architecture/nvidia-gpu-architecture-overview.adoc +++ b/architecture/nvidia-gpu-architecture-overview.adoc @@ -18,7 +18,9 @@ The NVIDIA GPU Operator is only supported by NVIDIA. For more information about ==== include::modules/nvidia-gpu-prerequisites.adoc[leveloffset=+1] + // New enablement modules +ifndef::openshift-dedicated,openshift-rosa[] include::modules/nvidia-gpu-enablement.adoc[leveloffset=+1] include::modules/nvidia-gpu-bare-metal.adoc[leveloffset=+2] @@ -45,11 +47,22 @@ include::modules/nvidia-gpu-csps.adoc[leveloffset=+2] [role="_additional-resources"] .Additional resources * link:https://docs.nvidia.com/ai-enterprise/deployment-guide-cloud/0.1.0/aws-redhat-openshift.html[Red Hat Openshift in the Cloud] +endif::openshift-dedicated,openshift-rosa[] +// Include this module at a higher leveloffset for OSD/ROSA. +ifdef::openshift-dedicated,openshift-rosa[] +include::modules/nvidia-gpu-csps.adoc[leveloffset=+1] +[role="_additional-resources"] +.Additional resources +* link:https://docs.nvidia.com/ai-enterprise/deployment-guide-cloud/0.1.0/aws-redhat-openshift.html[Red Hat Openshift in the Cloud] +endif::openshift-dedicated,openshift-rosa[] + +ifndef::openshift-dedicated,openshift-rosa[] include::modules/nvidia-gpu-red-hat-device-edge.adoc[leveloffset=+2] [role="_additional-resources"] .Additional resources * link:https://cloud.redhat.com/blog/how-to-accelerate-workloads-with-nvidia-gpus-on-red-hat-device-edge[How to accelerate workloads with NVIDIA GPUs on Red Hat Device Edge] +endif::openshift-dedicated,openshift-rosa[] // TELCODOCS-1092 GPU sharing methods include::modules/nvidia-gpu-sharing-methods.adoc[leveloffset=+1] @@ -85,4 +98,7 @@ include::modules/nvidia-gpu-features.adoc[leveloffset=+1] * link:https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/mig-ocp.html[MIG Support in OpenShift Container Platform] * link:https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/time-slicing-gpus-in-openshift.html[Time-slicing NVIDIA GPUs in OpenShift] * link:https://docs.nvidia.com/datacenter/cloud-native/openshift/latest/mirror-gpu-ocp-disconnected.html[Deploy GPU Operators in a disconnected or airgapped environment] +// Topic not available in OSD/ROSA +ifndef::openshift-dedicated,openshift-rosa[] * xref:../hardware_enablement/psap-node-feature-discovery-operator.html[Node Feature Discovery Operator] +endif::openshift-dedicated,openshift-rosa[] diff --git a/rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc b/architecture/rosa-architecture-models.adoc similarity index 56% rename from rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc rename to architecture/rosa-architecture-models.adoc index cec3777658..7e1030c1a0 100644 --- a/rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc +++ b/architecture/rosa-architecture-models.adoc @@ -9,19 +9,22 @@ toc::[] {product-rosa} (ROSA) has the following cluster topologies: -* Hosted control plane (HCP) - The control plane is hosted in a Red Hat account and the worker nodes are deployed in the customer's AWS account. +* Hosted control plane (HCP) - The control plane is hosted in a Red{nbsp}Hat account and the worker nodes are deployed in the customer's AWS account. * Classic - The control plane and the worker nodes are deployed in the customer's AWS account. include::modules/rosa-hcp-classic-comparison.adoc[leveloffset=+1] .Additional resources -* For AWS region availability, see the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-regions-az_rosa-hcp-service-definition[{hcp-title} regions and availability zones]. - -* For compliance status, see the xref:../../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-compliance_rosa-policy-process-security[security and regulation compliance] documentation. +* xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-sdpolicy-regions-az_rosa-hcp-service-definition[Regions and availability zones] +* xref:../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-security-regulation-compliance_rosa-policy-process-security[Security and regulation compliance] include::modules/rosa-hcp-architecture.adoc[leveloffset=+1] include::modules/rosa-architecture.adoc[leveloffset=+1] include::modules/osd-aws-privatelink-architecture.adoc[leveloffset=+2] include::modules/rosa-architecture-local-zones.adoc[leveloffset=+2] + +.Additional resources + +* xref:../rosa_cluster_admin/rosa_nodes/rosa-nodes-machinepools-configuring.html[Configuring machine pools in Local Zones] diff --git a/architecture/understanding-development.adoc b/architecture/understanding-development.adoc index 80d8f6d4d7..28e8b1afff 100644 --- a/architecture/understanding-development.adoc +++ b/architecture/understanding-development.adoc @@ -149,8 +149,7 @@ these runtime base images are referred to as Source-to-Image (S2I) images. With S2I images, you can insert your code into a base image environment that is ready to run that code. -S2I images are available for you to use directly from the {product-title} web UI -by selecting *Catalog* -> *Developer Catalog*, as shown in the following figure: +S2I images are available for you to use directly from the {product-title} web UI. In the Developer perspective, navigate to the *+Add* view and in the *Developer Catalog* tile, view all of the available services in the Developer Catalog. .Choose S2I base images for apps that need specific runtimes image::developer-catalog.png[{product-title} Developer Catalog] @@ -260,7 +259,14 @@ are added to your `Pod` definitions. After you define a group of pods that compose your application, you can define those pods in link:https://kubernetes.io/docs/concepts/workloads/controllers/deployment/[`Deployment`] -and xref:../applications/deployments/what-deployments-are.adoc#what-deployments-are[`DeploymentConfig`] objects. +and +// This xref points to a topic that is not currently included in the OSD/ROSA docs. +ifndef::openshift-dedicated,openshift-rosa[] +xref:../applications/deployments/what-deployments-are.adoc#what-deployments-are[`DeploymentConfig`] objects. +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +`DeploymentConfig` objects. +endif::openshift-dedicated,openshift-rosa[] [id="application-types"] === Application types @@ -277,8 +283,16 @@ application might not run again then for a month. Suitable {product-title} objects for these types of applications include link:https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/[`Job`] and https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/[`CronJob`] objects. + * Expected to run continuously. For long-running applications, you can write a +// This xref points to a topic that is not currently included in the OSD/ROSA docs. +ifndef::openshift-dedicated,openshift-rosa[] xref:../applications/deployments/what-deployments-are.adoc#deployments-kube-deployments[deployment]. +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +deployment. +endif::openshift-dedicated,openshift-rosa[] + * Required to be highly available. If your application requires high availability, then you want to size your deployment to have more than one instance. A `Deployment` or `DeploymentConfig` object can incorporate a diff --git a/images/developer-catalog.png b/images/developer-catalog.png index e72996af91..955b3823e1 100644 Binary files a/images/developer-catalog.png and b/images/developer-catalog.png differ diff --git a/images/oke-arch-ocp-stack.png b/images/oke-arch-ocp-stack.png index 92af5f6f7b..b8c1865d50 100644 Binary files a/images/oke-arch-ocp-stack.png and b/images/oke-arch-ocp-stack.png differ diff --git a/modules/admission-webhooks-about.adoc b/modules/admission-webhooks-about.adoc index 7b31780972..07036f57c8 100644 --- a/modules/admission-webhooks-about.adoc +++ b/modules/admission-webhooks-about.adoc @@ -9,26 +9,12 @@ In addition to {product-title} default admission plugins, dynamic admission can There are two types of webhook admission plugins in {product-title}: -ifndef::openshift-rosa,openshift-dedicated[] //Future xref - * During the admission process, xref:../architecture/admission-plug-ins.adoc#mutating-admission-plug-in[the mutating admission plugin] can perform tasks, such as injecting affinity labels. -endif::openshift-rosa,openshift-dedicated[] -ifdef::openshift-rosa[] -//Future xref - * During the admission process, xref:../rosa_architecture/rosa-admission-plug-ins.adoc#mutating-admission-plug-in[the mutating admission plugin] can perform tasks, such as injecting affinity labels. -endif::openshift-rosa[] -ifdef::openshift-dedicated[] -//Future xref - * During the admission process, xref:../osd_architecture/osd-admission-plug-ins.adoc#mutating-admission-plug-in[the mutating admission plugin] can perform tasks, such as injecting affinity labels. -endif::openshift-dedicated[] + * During the admission process, the _mutating admission plugin_ can perform tasks, such as injecting affinity labels. -ifndef::openshift-rosa,openshift-dedicated[] //Future xref - * At the end of the admission process, xref:../architecture/admission-plug-ins.adoc#validating-admission-plug-in[the validating admission plugin] makes sure an object is configured properly, for example ensuring affinity labels are as expected. If the validation passes, {product-title} schedules the object as configured. -endif::openshift-rosa,openshift-dedicated[] -ifdef::openshift-rosa[] -//Future xref - * At the end of the admission process, xref:../rosa_architecture/rosa-admission-plug-ins.html#validating-admission-plug-in_admission-plug-ins[the validating admission plugin] makes sure an object is configured properly, for example ensuring affinity labels are as expected. If the validation passes, {product-title} schedules the object as configured. -endif::openshift-rosa[] -ifdef::openshift-dedicated[] -//Future xref - * At the end of the admission process, xref:../osd_architecture/osd-admission-plug-ins.html#validating-admission-plug-in_admission-plug-ins[the validating admission plugin] makes sure an object is configured properly, for example ensuring affinity labels are as expected. If the validation passes, {product-title} schedules the object as configured. -endif::openshift-dedicated[] + * At the end of the admission process, the _validating admission plugin_ can be used to make sure an object is configured properly, for example ensuring affinity labels are as expected. If the validation passes, {product-title} schedules the object as configured. When an API request comes in, mutating or validating admission plugins use the list of external webhooks in the configuration and call them in parallel: diff --git a/modules/architecture-machine-roles.adoc b/modules/architecture-machine-roles.adoc index 9243250b1b..a450a6898d 100644 --- a/modules/architecture-machine-roles.adoc +++ b/modules/architecture-machine-roles.adoc @@ -7,11 +7,14 @@ {product-title} assigns hosts different roles. These roles define the function of the machine within the cluster. The cluster contains definitions for the standard `master` and `worker` role types. +ifndef::openshift-dedicated,openshift-rosa[] [NOTE] ==== The cluster also contains the definition for the `bootstrap` role. Because the bootstrap machine is used only during cluster installation, its function is explained in the cluster installation documentation. ==== +endif::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa[] == Control plane and node host compatibility The {product-title} version must match between control plane host and node host. For example, in a {product-version} cluster, all control plane hosts must be {product-version} and all nodes must be {product-version}. @@ -37,11 +40,17 @@ The `kubelet` service must not be newer than `kube-apiserver`, and can be up to 1. For example, {product-title} 4.11, 4.13. 2. For example, {product-title} 4.10, 4.12. -- +endif::openshift-dedicated,openshift-rosa[] [id="defining-workers_{context}"] == Cluster workers -In a Kubernetes cluster, the worker nodes are where the actual workloads requested by Kubernetes users run and are managed. The worker nodes advertise their capacity and the scheduler, which a control plane service, determines on which nodes to start pods and containers. Important services run on each worker node, including CRI-O, which is the container engine; Kubelet, which is the service that accepts and fulfills requests for running and stopping container workloads; a service proxy, which manages communication for pods across workers; and the runC or crun low-level container runtime, which creates and runs containers. +In a Kubernetes cluster, worker nodes run and manage the actual workloads requested by Kubernetes users. The worker nodes advertise their capacity and the scheduler, which is a control plane service, determines on which nodes to start pods and containers. The following important services run on each worker node: + +* CRI-O, which is the container engine. +* kubelet, which is the service that accepts and fulfills requests for running and stopping container workloads. +* A service proxy, which manages communication for pods across workers. +* The runC or crun low-level container runtime, which creates and runs containers. [NOTE] ==== @@ -60,11 +69,23 @@ Compute machine sets are groupings of compute machine resources under the `machi In a Kubernetes cluster, the _master_ nodes run services that are required to control the Kubernetes cluster. In {product-title}, the control plane is comprised of control plane machines that have a `master` machine role. They contain more than just the Kubernetes services for managing the {product-title} cluster. -For most {product-title} clusters, control plane machines are defined by a series of standalone machine API resources. For supported cloud provider and {product-title} version combinations, control planes can be managed with control plane machine sets. Extra controls apply to control plane machines to prevent you from deleting all control plane machines and breaking your cluster. +For most {product-title} clusters, control plane machines are defined by a series of standalone machine API resources. +ifndef::openshift-dedicated,openshift-rosa[] +For supported cloud provider and {product-title} version combinations, control planes can be managed with control plane machine sets. +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +Control planes are managed with control plane machine sets. +endif::openshift-dedicated,openshift-rosa[] +Extra controls apply to control plane machines to prevent you from deleting all of the control plane machines and breaking your cluster. [NOTE] ==== +ifndef::openshift-dedicated,openshift-rosa[] Exactly three control plane nodes must be used for all production deployments. +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +Single availability zone clusters and multiple availability zone clusters require a minimum of three control plane nodes. +endif::openshift-dedicated,openshift-rosa[] ==== Services that fall under the Kubernetes category on the control plane include the Kubernetes API server, etcd, the Kubernetes controller manager, and the Kubernetes scheduler. diff --git a/modules/architecture-platform-benefits.adoc b/modules/architecture-platform-benefits.adoc index 776c8f137c..df4925e21e 100644 --- a/modules/architecture-platform-benefits.adoc +++ b/modules/architecture-platform-benefits.adoc @@ -30,7 +30,13 @@ unique features and benefits of {product-title}. [id="architecture-custom-os_{context}"] == Custom operating system +ifndef::openshift-dedicated,openshift-rosa[] {product-title} uses {op-system-first}, a container-oriented operating system that is specifically designed for running containerized applications from {product-title} and works with new tools to provide fast installation, Operator-based management, and simplified upgrades. +endif::openshift-dedicated,openshift-rosa[] + +ifdef::openshift-dedicated,openshift-rosa[] +{product-title} uses {op-system-first} as the operating system for all control plane and worker nodes. +endif::openshift-dedicated,openshift-rosa[] {op-system} includes: @@ -39,15 +45,23 @@ unique features and benefits of {product-title}. * Kubelet, the primary node agent for Kubernetes that is responsible for launching and monitoring containers. +ifndef::openshift-dedicated,openshift-rosa[] In {product-title} {product-version}, you must use {op-system} for all control plane machines, but you can use Red Hat Enterprise Linux (RHEL) as the operating system for compute machines, which are also known as worker machines. If you choose to use RHEL workers, you must perform more system maintenance than if you use {op-system} for all of the cluster machines. +endif::openshift-dedicated,openshift-rosa[] [id="architecture-platform-management_{context}"] +ifndef::openshift-dedicated,openshift-rosa[] == Simplified installation and update process +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +== Simplified update process +endif::openshift-dedicated,openshift-rosa[] +ifndef::openshift-dedicated,openshift-rosa[] With {product-title} {product-version}, if you have an account with the right permissions, you can deploy a production cluster in supported clouds by running a single command and providing a few values. You can also customize your cloud @@ -61,6 +75,11 @@ machine, including the operating system itself, from a central control plane, upgrades are designed to become automatic events. If your cluster contains RHEL worker machines, the control plane benefits from the streamlined update process, but you must perform more tasks to upgrade the RHEL machines. +endif::openshift-dedicated,openshift-rosa[] + +ifdef::openshift-dedicated,openshift-rosa[] +Updating, or upgrading, {product-title} is a simple, highly-automated process. Because {product-title} completely controls the systems and services that run on each machine, including the operating system itself, from a central control plane, upgrades are designed to become automatic events. +endif::openshift-dedicated,openshift-rosa[] [id="architecture-key-features_{context}"] == Other key features @@ -109,7 +128,7 @@ It also offers the following user interfaces: * Rest API //// - +ifndef::openshift-dedicated,openshift-rosa[] [id="architecture-overview-image_{context}"] == {product-title} lifecycle @@ -122,3 +141,4 @@ The following figure illustrates the basic {product-title} lifecycle: .High level {product-title} overview image::product-workflow-overview.png[High-level {product-title} flow] +endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/etcd-overview.adoc b/modules/etcd-overview.adoc index 077d8f3d00..c76e0319a3 100644 --- a/modules/etcd-overview.adoc +++ b/modules/etcd-overview.adoc @@ -29,4 +29,10 @@ The etcd Operator observes, analyzes, and acts: . It analyzes differences between the current state and the state that you want. . It fixes the differences through the etcd cluster management APIs, the Kubernetes API, or both. -etcd holds the cluster state, which is constantly updated. This state is continuously persisted, which leads to a high number of small changes at high frequency. As a result, it is critical to back the etcd cluster member with fast, low-latency I/O. For more information about best practices for etcd, see "Recommended etcd practices". +etcd holds the cluster state, which is constantly updated. This state is continuously persisted, which leads to a high number of small changes at high frequency. +ifndef::openshift-dedicated,openshift-rosa[] +As a result, it is critical to back the etcd cluster member with fast, low-latency I/O. For more information about best practices for etcd, see "Recommended etcd practices". +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-dedicated,openshift-rosa[] +As a result, Red Hat Site Reliability Engineering (SRE) backs the etcd cluster member with fast, low-latency I/O. +endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/nvidia-gpu-csps.adoc b/modules/nvidia-gpu-csps.adoc index f4ad3ce96f..98f70d1404 100644 --- a/modules/nvidia-gpu-csps.adoc +++ b/modules/nvidia-gpu-csps.adoc @@ -4,8 +4,17 @@ :_mod-docs-content-type: CONCEPT [id="nvidia-gpu-csps_{context}"] +ifndef::openshift-dedicated,openshift-rosa[] = GPUs and CSPs +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-rosa[] += GPUs and ROSA +endif::openshift-rosa[] +ifdef::openshift-dedicated[] += GPUs and OSD +endif::openshift-dedicated[] +ifndef::openshift-dedicated,openshift-rosa[] You can deploy {product-title} to one of the major cloud service providers (CSPs): Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure. Two modes of operation are available: a fully managed deployment and a self-managed deployment. @@ -13,6 +22,11 @@ Two modes of operation are available: a fully managed deployment and a self-mana * In a fully managed deployment, everything is automated by Red Hat in collaboration with CSP. You can request an OpenShift instance through the CSP web console, and the cluster is automatically created and fully managed by Red Hat. You do not have to worry about node failures or errors in the environment. Red Hat is fully responsible for maintaining the uptime of the cluster. The fully managed services are available on AWS and Azure. For AWS, the OpenShift service is called ROSA (Red Hat OpenShift Service on AWS). For Azure, the service is called Azure Red Hat OpenShift. * In a self-managed deployment, you are responsible for instantiating and maintaining the OpenShift cluster. Red Hat provides the OpenShift-install utility to support the deployment of the OpenShift cluster in this case. The self-managed services are available globally to all CSPs. +endif::openshift-dedicated,openshift-rosa[] + +ifdef::openshift-dedicated,openshift-rosa[] +You can deploy {product-title} on NVIDIA GPU instance types. +endif::openshift-dedicated,openshift-rosa[] It is important that this compute instance is a GPU-accelerated compute instance and that the GPU type matches the list of supported GPUs from NVIDIA AI Enterprise. For example, T4, V100, and A100 are part of this list. diff --git a/modules/nvidia-gpu-sharing-methods.adoc b/modules/nvidia-gpu-sharing-methods.adoc index 41658f2a3f..ef9e2fe440 100644 --- a/modules/nvidia-gpu-sharing-methods.adoc +++ b/modules/nvidia-gpu-sharing-methods.adoc @@ -18,6 +18,7 @@ Concurrency mechanisms for improving GPU utilization exist that range from progr * Multi-instance GPU (MIG) * Virtualization with vGPU +ifndef::openshift-dedicated,openshift-rosa[] Consider the following GPU sharing suggestions when using the GPU concurrency mechanisms for different {product-title} scenarios: Bare metal:: vGPU is not available. Consider using MIG-enabled cards. @@ -25,3 +26,4 @@ VMs:: vGPU is the best choice. Older NVIDIA cards with no MIG on bare metal:: Consider using time-slicing. VMs with multiple GPUs and you want passthrough and vGPU:: Consider using separate VMs. Bare metal with {VirtProductName} and multiple GPUs:: Consider using pass-through for hosted VMs and time-slicing for containers. +endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/openshift-architecture-common-terms.adoc b/modules/openshift-architecture-common-terms.adoc index ce9fca3940..d863bb384a 100644 --- a/modules/openshift-architecture-common-terms.adoc +++ b/modules/openshift-architecture-common-terms.adoc @@ -9,13 +9,23 @@ This glossary defines common terms that are used in the architecture content. access policies:: -A set of roles that dictate how users, applications, and entities within a cluster interacts with one another. An access policy increases cluster security. +A set of roles that dictate how users, applications, and entities within a cluster interact with one another. An access policy increases cluster security. admission plugins:: Admission plugins enforce security policies, resource limitations, or configuration requirements. authentication:: -To control access to an {product-title} cluster, a cluster administrator can configure user authentication and ensure only approved users access the cluster. To interact with an {product-title} cluster, you must authenticate to the {product-title} API. You can authenticate by providing an OAuth access token or an X.509 client certificate in your requests to the {product-title} API. +// The following variations have only minor differences, but are separated for +// maintainability. +ifndef::openshift-dedicated,openshift-rosa[] +To control access to an {product-title} cluster, a cluster administrator can configure user authentication to ensure only approved users access the cluster. To interact with an {product-title} cluster, you must authenticate with the {product-title} API. You can authenticate by providing an OAuth access token or an X.509 client certificate in your requests to the {product-title} API. +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-rosa[] +To control access to a {product-title} cluster, an administrator with the `dedicated-admin` role can configure user authentication to ensure only approved users access the cluster. To interact with a {product-title} cluster, you must authenticate with the {product-title} API. You can authenticate by providing an OAuth access token or an X.509 client certificate in your requests to the {product-title} API. +endif::openshift-rosa[] +ifdef::openshift-dedicated[] +To control access to an {product-title} cluster, an administrator with the `dedicated-admin` role can configure user authentication to ensure only approved users access the cluster. To interact with an {product-title} cluster, you must authenticate with the {product-title} API. You can authenticate by providing an OAuth access token or an X.509 client certificate in your requests to the {product-title} API. +endif::openshift-dedicated[] bootstrap:: A temporary machine that runs minimal Kubernetes and deploys the {product-title} control plane. @@ -33,7 +43,7 @@ configuration drift:: A situation where the configuration on a node does not match what the machine config specifies. containers:: -Lightweight and executable images that consist software and all its dependencies. Because containers virtualize the operating system, you can run containers anywhere, from a data center to a public or private cloud to your local host. +Lightweight and executable images that consist of software and all of its dependencies. Because containers virtualize the operating system, you can run containers anywhere, such as data centers, public or private clouds, and local hosts. container orchestration engine:: Software that automates the deployment, management, scaling, and networking of containers. @@ -57,11 +67,11 @@ Dockerfile:: A text file that contains the user commands to perform on a terminal to assemble the image. hosted control planes:: -A {product-title} feature that enables hosting a control plane on the {product-title} cluster from its data plane and workers. This model performs following actions: +A {product-title} feature that enables hosting a control plane on the {product-title} cluster from its data plane and workers. This model performs the following actions: * Optimize infrastructure costs required for the control planes. * Improve the cluster creation time. -* Enable hosting the control plane using the Kubernetes native high level primitives. For example, deployments, stateful sets. +* Enable hosting the control plane using the Kubernetes native high level primitives. For example, deployments and stateful sets. * Allow a strong network segmentation between the control plane and workloads. hybrid cloud deployments:: @@ -109,20 +119,29 @@ Network information of {product-title} cluster. node:: A worker machine in the {product-title} cluster. A node is either a virtual machine (VM) or a physical machine. -{product-title} Update Service (OSUS):: -For clusters with internet access, {op-system-base-full} provides over-the-air updates by using an {product-title} update service as a hosted service located behind public APIs. - OpenShift CLI (`oc`):: A command line tool to run {product-title} commands on the terminal. +ifndef::openshift-dedicated,openshift-rosa[] OpenShift Dedicated:: A managed {op-system-base} {product-title} offering on Amazon Web Services (AWS) and Google Cloud Platform (GCP). OpenShift Dedicated focuses on building and scaling applications. +endif::openshift-dedicated,openshift-rosa[] + +OpenShift Update Service (OSUS):: +For clusters with internet access, {op-system-base-full} provides over-the-air updates by using an OpenShift update service as a hosted service located behind public APIs. {product-registry}:: A registry provided by {product-title} to manage images. Operator:: -The preferred method of packaging, deploying, and managing a Kubernetes application in an {product-title} cluster. An Operator takes human operational knowledge and encodes it into software that is packaged and shared with customers. +The preferred method of packaging, deploying, and managing a Kubernetes application in +ifdef::openshift-rosa[] +a +endif::openshift-rosa[] +ifndef::openshift-rosa[] +an +endif::openshift-rosa[] +{product-title} cluster. An Operator takes human operational knowledge and encodes it into software that is packaged and shared with customers. OperatorHub:: A platform that contains various {product-title} Operators to install. @@ -137,8 +156,7 @@ over-the-air (OTA) updates:: The {product-title} Update Service (OSUS) provides over-the-air updates to {product-title}, including {op-system-first}. pod:: -One or more containers with shared resources, such as volume and IP addresses, running in your {product-title} cluster. -A pod is the smallest compute unit defined, deployed, and managed. +One or more containers with shared resources, such as volume and IP addresses, running in your {product-title} cluster. A pod is the smallest compute unit defined, deployed, and managed. private registry:: {product-title} can use any server implementing the container image registry API as a source of the image which allows the developers to push and pull their private container images. @@ -171,7 +189,17 @@ Source-to-Image (S2I) image:: An image created based on the programming language of the application source code in {product-title} to deploy applications. storage:: +// OSD and ROSA definitions are separated here due to different indefinite +// articles. +ifndef::openshift-dedicated,openshift-rosa[] {product-title} supports many types of storage, both for on-premise and cloud providers. You can manage container storage for persistent and non-persistent data in an {product-title} cluster. +endif::openshift-dedicated,openshift-rosa[] +ifdef::openshift-rosa[] +{product-title} supports many types of storage for cloud providers. You can manage container storage for persistent and non-persistent data in a {product-title} cluster. +endif::openshift-rosa[] +ifdef::openshift-dedicated[] +{product-title} supports many types of storage for cloud providers. You can manage container storage for persistent and non-persistent data in an {product-title} cluster. +endif::openshift-dedicated[] Telemetry:: A component to collect information such as size, health, and status of {product-title}. @@ -179,8 +207,10 @@ A component to collect information such as size, health, and status of {product- template:: A template describes a set of objects that can be parameterized and processed to produce a list of objects for creation by {product-title}. +ifndef::openshift-dedicated,openshift-rosa[] user-provisioned infrastructure:: You can install {product-title} on the infrastructure that you provide. You can use the installation program to generate the assets required to provision the cluster infrastructure, create the cluster infrastructure, and then deploy the cluster to the infrastructure that you provided. +endif::openshift-dedicated,openshift-rosa[] web console:: A user interface (UI) to manage {product-title}. diff --git a/modules/osd-vs-ocp.adoc b/modules/osd-vs-ocp.adoc deleted file mode 100644 index 2dd08f7d7a..0000000000 --- a/modules/osd-vs-ocp.adoc +++ /dev/null @@ -1,39 +0,0 @@ -// Module included in the following assemblies: -// -// * osd_architecture/osd-architecture.adoc - -:_mod-docs-content-type: CONCEPT -[id="osd-vs-ocp_{context}"] - -= Understanding how {product-title} differs from {OCP} - -{product-title} uses the same code base as {OCP} but is installed in an opinionated way to be optimized for performance, scalability, and security. {product-title} is a fully managed service; therefore, many of the {product-title} components and settings that you manually set up in {OCP} are set up for you by default. - -Review the following differences between {product-title} and a standard installation of {OCP} on your own infrastructure: - -[options="header"] -|==== -|{OCP} |{product-title} - -|The customer installs and configures {OCP}. -|{product-title} is installed through a user-friendly webpage and in a standardized way that is optimized for performance, scalability, and security. - -|Customers can choose their computing resources. -|{product-title} is hosted and managed in a public cloud (Amazon Web Services or Google Cloud Platform) either owned by Red Hat or provided by the customer. - -|Customers have top-level administrative access to the infrastructure. -|Customers have a built-in administrator group, though the top-level administration access is available when cloud accounts are provided by the customer. - -|Customers can use all supported features and configuration settings available in {OCP}. -|Some {OCP} features and configuration settings might not be available or changeable in {product-title} . - -|You set up control plane components such as the API server and etcd on machines that get the `control` role. You can modify the control plane components, but keep in mind that you are responsible for backing up, restoring, and making control plane data highly available. -|Red Hat sets up the control plane and manages the control plane components for you. The control plane is highly available. - -|You are responsible for updating the underlying infrastructure for the control plane and worker nodes. You can use the OpenShift web console to update {OCP} versions. -|Red Hat automatically notifies the customer when updates are available. You can manually or automatically schedule upgrades in {cluster-manager-first}. - -|Support is provided based on the terms of your Red Hat subscription or cloud provider. -|Engineered, operated, and supported by Red Hat with a 99.95% uptime SLA and link:https://access.redhat.com/support/offerings/openshift/sla[24x7] coverage. - -|==== diff --git a/modules/rosa-architecture-local-zones.adoc b/modules/rosa-architecture-local-zones.adoc index 4d8c3371b0..64eee6d21d 100644 --- a/modules/rosa-architecture-local-zones.adoc +++ b/modules/rosa-architecture-local-zones.adoc @@ -1,11 +1,11 @@ // Module included in the following assemblies: // -// * rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc +// * architecture/rosa-architecture-models.adoc :_mod-docs-content-type: REFERENCE [id="rosa-architecture-local-zones_{context}"] = ROSA architecture with Local Zones -ROSA supports the use of AWS Local Zones, which are metropolis-centralized availability zones where customers can place latency-sensitive application workloads within a VPC. Local Zones are extensions of AWS Regions and are not enabled by default. When Local Zones are enabled and configured, the traffic is extended into the Local Zones for greater flexibility and lower latency. For more information, see xref:../../rosa_cluster_admin/rosa_nodes/rosa-nodes-machinepools-configuring.html[Configuring machine pools in Local Zones]. +ROSA supports the use of AWS Local Zones, which are metropolis-centralized availability zones where customers can place latency-sensitive application workloads within a VPC. Local Zones are extensions of AWS Regions and are not enabled by default. When Local Zones are enabled and configured, the traffic is extended into the Local Zones for greater flexibility and lower latency. For more information, see "Configuring machine pools in Local Zones". The following diagram displays a ROSA cluster without traffic routed into a Local Zone. diff --git a/modules/sd-vs-ocp.adoc b/modules/sd-vs-ocp.adoc new file mode 100644 index 0000000000..16bba8a5ab --- /dev/null +++ b/modules/sd-vs-ocp.adoc @@ -0,0 +1,57 @@ +// Module included in the following assemblies: +// +// * architecture/index.adoc + +:_mod-docs-content-type: CONCEPT +[id="sd-vs-ocp_{context}"] + += Understanding how {product-title} differs from {OCP} + +{product-title} uses the same code base as {OCP} but is installed in an opinionated way to be optimized for performance, scalability, and security. {product-title} is a fully managed service; therefore, many of the {product-title} components and settings that you manually set up in {OCP} are set up for you by default. + +Review the following differences between {product-title} and a standard installation of {OCP} on your own infrastructure: + +[options="header"] +|==== +|{OCP} |{product-title} + +|The customer installs and configures {OCP}. +| +ifdef::openshift-dedicated[] +{product-title} is installed through {cluster-manager-first} and in a standardized way that is optimized for performance, scalability, and security. +endif::openshift-dedicated[] +ifdef::openshift-rosa[] +{product-title} is installed through {cluster-manager-first} or the ROSA CLI (`rosa`) and in a standardized way that is optimized for performance, scalability, and security. +endif::openshift-rosa[] + +|Customers can choose their computing resources. +| +ifdef::openshift-dedicated[] +{product-title} is hosted and managed in a public cloud (Amazon Web Services or Google Cloud Platform) either owned by Red{nbsp}Hat or provided by the customer. +endif::openshift-dedicated[] +ifdef::openshift-rosa[] +{product-title} is hosted and managed in a public cloud (Amazon Web Services) provided by the customer. +endif::openshift-rosa[] + +|Customers have top-level administrative access to the infrastructure. +| +ifdef::openshift-dedicated[] +Customers have a built-in administrator group (`dedicated-admin`), though the top-level administration access is available when cloud accounts are provided by the customer. +endif::openshift-dedicated[] +ifdef::openshift-rosa[] +Customers have a built-in administrator group (`dedicated-admin`), though the top-level administration access is available. +endif::openshift-rosa[] + +|Customers can use all supported features and configuration settings available in {OCP}. +|Some {OCP} features and configuration settings might not be available or changeable in {product-title}. + +|You set up control plane components such as the API server and etcd on machines that get the `control` role. You can modify the control plane components, but are responsible for backing up, restoring, and making control plane data highly available. +|Red Hat sets up the control plane and manages the control plane components for you. The control plane is highly available. + +|You are responsible for updating the underlying infrastructure for the control plane and worker nodes. You can use the OpenShift web console to update {OCP} versions. +|Red{nbsp}Hat automatically notifies the customer when updates are available. You can manually or automatically schedule updates in {cluster-manager}. + +|Support is provided based on the terms of your Red Hat subscription or cloud provider. +|Engineered, operated, and supported by Red Hat with a 99.95% uptime SLA and 24x7 coverage. For details, see link:https://www.redhat.com/licenses/Appendix-4-Red-Hat-Online-Services-20230523.pdf[Red Hat Enterprise Agreement Appendix 4 (Online Subscription Services)]. + +|==== diff --git a/operators/index.adoc b/operators/index.adoc index facd291c50..4fea6077aa 100644 --- a/operators/index.adoc +++ b/operators/index.adoc @@ -10,20 +10,6 @@ include::modules/operators-overview.adoc[leveloffset=+1] With Operators, you can create applications to monitor the running services in the cluster. Operators are designed specifically for your applications. Operators implement and automate the common Day 1 operations such as installation and configuration as well as Day 2 operations such as autoscaling up and down and creating backups. All these activities are in a piece of software running inside your cluster. -// Include Cluster Operators and Add-on Operators for OSD/ROSA. These modules are in architecture/control-place.adoc, but this assembly is not currently included in the OSD/ROSA docs. -ifdef::openshift-dedicated,openshift-rosa[] - -== Operators in {product-title} -include::modules/arch-cluster-operators.adoc[leveloffset=+2] - -include::modules/arch-olm-operators.adoc[leveloffset=+2] - -[role="_additional-resources"] -.Additional resources -* For more details on running add-on Operators in {product-title}, see the _Operators_ guide sections on xref:../operators/understanding/olm/olm-understanding-olm.adoc#olm-understanding-olm[Operator Lifecycle Manager (OLM)] and xref:../operators/understanding/olm-understanding-operatorhub.adoc#olm-understanding-operatorhub[OperatorHub]. -* For more details on the Operator SDK, see xref:../operators/operator_sdk/osdk-about.adoc#osdk-about[Developing Operators]. -endif::openshift-dedicated,openshift-rosa[] - [id="operators-overview-developer-tasks"] == For developers diff --git a/osd_getting_started/osd-getting-started.adoc b/osd_getting_started/osd-getting-started.adoc index b0d7dab4a3..a8ffe37b85 100644 --- a/osd_getting_started/osd-getting-started.adoc +++ b/osd_getting_started/osd-getting-started.adoc @@ -12,7 +12,7 @@ Follow this getting started document to quickly create a {product-title} cluster [id="osd-getting-started-prerequisites"] == Prerequisites -* You reviewed the xref:../osd_architecture/osd-understanding.adoc#osd-understanding[introduction to {product-title}] and the documentation on xref:../osd_architecture/osd-architecture.adoc#osd-architecture[architecture concepts]. +* You reviewed the xref:../osd_architecture/osd-understanding.adoc#osd-understanding[introduction to {product-title}] and the documentation on xref:../architecture/index.adoc#architecture-overview[architecture concepts]. * You reviewed the xref:../osd_getting_started/osd-understanding-your-cloud-deployment-options.adoc#osd-understanding-your-cloud-deployment-options[{product-title} cloud deployment options]. [id="osd-getting-started-create-cluster"] diff --git a/osd_install_access_delete_cluster/creating-a-gcp-cluster.adoc b/osd_install_access_delete_cluster/creating-a-gcp-cluster.adoc index 40a88864e7..3970b898d5 100644 --- a/osd_install_access_delete_cluster/creating-a-gcp-cluster.adoc +++ b/osd_install_access_delete_cluster/creating-a-gcp-cluster.adoc @@ -12,7 +12,7 @@ You can install {product-title} on {GCP} by using your own GCP account through t [id="osd-creating-a-cluster-on-gcp-prerequisites_{context}"] == Prerequisites -* You reviewed the xref:../osd_architecture/osd-understanding.adoc#osd-understanding[introduction to {product-title}] and the documentation on xref:../osd_architecture/osd-architecture.adoc#osd-architecture[architecture concepts]. +* You reviewed the xref:../osd_architecture/osd-understanding.adoc#osd-understanding[introduction to {product-title}] and the documentation on xref:../architecture/index.adoc#architecture-overview[architecture concepts]. * You reviewed the xref:../osd_getting_started/osd-understanding-your-cloud-deployment-options.adoc#osd-understanding-your-cloud-deployment-options[{product-title} cloud deployment options]. include::modules/osd-create-cluster-ccs.adoc[leveloffset=+1] diff --git a/osd_install_access_delete_cluster/creating-an-aws-cluster.adoc b/osd_install_access_delete_cluster/creating-an-aws-cluster.adoc index 454c3cada2..796e4d14dc 100644 --- a/osd_install_access_delete_cluster/creating-an-aws-cluster.adoc +++ b/osd_install_access_delete_cluster/creating-an-aws-cluster.adoc @@ -12,7 +12,7 @@ You can install {product-title} on {AWS} by using your own AWS account through t [id="osd-creating-a-cluster-on-aws-prerequisites_{context}"] == Prerequisites -* You reviewed the xref:../osd_architecture/osd-understanding.adoc#osd-understanding[introduction to {product-title}] and the documentation on xref:../osd_architecture/osd-architecture.adoc#osd-architecture[architecture concepts]. +* You reviewed the xref:../osd_architecture/osd-understanding.adoc#osd-understanding[introduction to {product-title}] and the documentation on xref:../architecture/index.adoc#architecture-overview[architecture concepts]. * You reviewed the xref:../osd_getting_started/osd-understanding-your-cloud-deployment-options.adoc#osd-understanding-your-cloud-deployment-options[{product-title} cloud deployment options]. include::modules/osd-create-cluster-ccs.adoc[leveloffset=+1] diff --git a/rosa_architecture/rosa_architecture_sub/_attributes b/rosa_architecture/rosa_architecture_sub/_attributes deleted file mode 120000 index f27fd275ea..0000000000 --- a/rosa_architecture/rosa_architecture_sub/_attributes +++ /dev/null @@ -1 +0,0 @@ -../_attributes/ \ No newline at end of file diff --git a/rosa_architecture/rosa_architecture_sub/images b/rosa_architecture/rosa_architecture_sub/images deleted file mode 120000 index 5e67573196..0000000000 --- a/rosa_architecture/rosa_architecture_sub/images +++ /dev/null @@ -1 +0,0 @@ -../images \ No newline at end of file diff --git a/rosa_architecture/rosa_architecture_sub/modules b/rosa_architecture/rosa_architecture_sub/modules deleted file mode 120000 index 464b823aca..0000000000 --- a/rosa_architecture/rosa_architecture_sub/modules +++ /dev/null @@ -1 +0,0 @@ -../modules \ No newline at end of file diff --git a/rosa_architecture/rosa_architecture_sub/snippets b/rosa_architecture/rosa_architecture_sub/snippets deleted file mode 120000 index 9f5bc7e4dd..0000000000 --- a/rosa_architecture/rosa_architecture_sub/snippets +++ /dev/null @@ -1 +0,0 @@ -../snippets \ No newline at end of file diff --git a/rosa_getting_started/rosa-getting-started.adoc b/rosa_getting_started/rosa-getting-started.adoc index 63cf9b65fe..841f9f6ae1 100644 --- a/rosa_getting_started/rosa-getting-started.adoc +++ b/rosa_getting_started/rosa-getting-started.adoc @@ -18,7 +18,7 @@ You can create a ROSA cluster either with or without the AWS Security Token Serv [id="rosa-getting-started-prerequisites_{context}"] == Prerequisites -* You reviewed the xref:../rosa_architecture/rosa-understanding.adoc#rosa-understanding[introduction to {product-title} (ROSA)], and the documentation on ROSA xref:../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-architecture-models[architecture models] and xref:../rosa_architecture/rosa_architecture_sub/rosa-basic-architecture-concepts.adoc#rosa-basic-architecture-concepts[architecture concepts]. +* You reviewed the xref:../rosa_architecture/rosa-understanding.adoc#rosa-understanding[introduction to {product-title} (ROSA)], and the documentation on ROSA xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[architecture models] and xref:../architecture/architecture.adoc#architecture[architecture concepts]. * You have read the documentation on xref:../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[limits and scalability] and the xref:../rosa_planning/rosa-planning-environment.adoc#rosa-planning-environment[guidelines for planning your environment]. diff --git a/rosa_getting_started/rosa-quickstart-guide-ui.adoc b/rosa_getting_started/rosa-quickstart-guide-ui.adoc index 8b1dbb9b9b..1143b2deaa 100644 --- a/rosa_getting_started/rosa-quickstart-guide-ui.adoc +++ b/rosa_getting_started/rosa-quickstart-guide-ui.adoc @@ -20,7 +20,7 @@ image::291_OpenShift_on_AWS_Intro_1122_docs.png[{product-title}] [id="rosa-getting-started-prerequisites_{context}"] == Prerequisites -* You reviewed the xref:../rosa_architecture/rosa-understanding.adoc#rosa-understanding[introduction to {product-title} (ROSA)], and the documentation on ROSA xref:../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-architecture-models[architecture models] and xref:../rosa_architecture/rosa_architecture_sub/rosa-basic-architecture-concepts.adoc#rosa-basic-architecture-concepts[architecture concepts]. +* You reviewed the xref:../rosa_architecture/rosa-understanding.adoc#rosa-understanding[introduction to {product-title} (ROSA)], and the documentation on ROSA xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[architecture models] and xref:../architecture/architecture.adoc#architecture[architecture concepts]. * You have read the documentation on xref:../rosa_planning/rosa-limits-scalability.adoc#rosa-limits-scalability[limits and scalability] and the xref:../rosa_planning/rosa-planning-environment.adoc#rosa-planning-environment[guidelines for planning your environment]. diff --git a/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc b/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc index f49a41586e..34964925bb 100644 --- a/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc +++ b/rosa_hcp/rosa-hcp-aws-private-creating-cluster.adoc @@ -24,5 +24,5 @@ xref:../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.a * xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS PrivateLink firewall prerequisites] * xref:../rosa_getting_started/rosa-sts-getting-started-workflow.adoc#rosa-sts-overview-of-the-deployment-workflow[Overview of the ROSA with STS deployment workflow] * xref:../rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc#rosa-sts-deleting-cluster[Deleting a ROSA cluster] -* xref:../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-architecture-models[Architecture models] +* xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[ROSA architecture models] * xref:../support/troubleshooting/rosa-troubleshooting-installations.adoc#rosa-troubleshooting-installing[Troubleshooting Red Hat OpenShift Service on AWS installations] diff --git a/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc b/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc index 409e2a932d..019ed1cadc 100644 --- a/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc +++ b/rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc @@ -26,9 +26,10 @@ Since it is not possible to upgrade or convert existing ROSA clusters to a {hcp} ==== .Further reading -* For a comparison between {hcp-title} and ROSA Classic, see the xref:../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-hcp-classic-comparison_rosa-architecture-models[Comparing architecture models] documentation. +* For a comparison between {hcp-title} and ROSA Classic, see the xref:../architecture/rosa-architecture-models.adoc#rosa-hcp-classic-comparison_rosa-architecture-models[Comparing architecture models] documentation. * See the AWS documentation for information about link:https://docs.aws.amazon.com/rosa/latest/userguide/getting-started-hcp.html[Getting started with ROSA with HCP using the ROSA CLI in auto mode]. +[role="_additional-resources"] .Additional resources For a full list of the supported certificates, see the xref:../rosa_architecture/rosa_policy_service_definition/rosa-policy-process-security.adoc#rosa-policy-compliance_rosa-policy-process-security[Compliance] section of "Understanding process and security for Red Hat OpenShift Service on AWS". diff --git a/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc b/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc index 57faa670a7..f30beff0bc 100644 --- a/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc +++ b/rosa_install_access_delete_clusters/rosa-aws-privatelink-creating-cluster.adoc @@ -22,4 +22,4 @@ xref:../rosa_install_access_delete_clusters/rosa-sts-config-identity-providers.a * xref:../rosa_planning/rosa-sts-aws-prereqs.adoc#osd-aws-privatelink-firewall-prerequisites_rosa-sts-aws-prereqs[AWS PrivateLink firewall prerequisites] * xref:../rosa_getting_started/rosa-sts-getting-started-workflow.adoc#rosa-sts-overview-of-the-deployment-workflow[Overview of the ROSA with STS deployment workflow] * xref:../rosa_install_access_delete_clusters/rosa-sts-deleting-cluster.adoc#rosa-sts-deleting-cluster[Deleting a ROSA cluster] -* xref:../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-architecture-models[ROSA architecture] +* xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[ROSA architecture models] diff --git a/rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-creating-cluster.adoc b/rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-creating-cluster.adoc index b383cb2f76..9c61d160de 100644 --- a/rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-creating-cluster.adoc +++ b/rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-creating-cluster.adoc @@ -23,4 +23,4 @@ xref:../../rosa_install_access_delete_clusters/rosa-sts-config-identity-provider * xref:../../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-getting-started-workflow.adoc#rosa-understanding-the-deployment-workflow[Understanding the ROSA deployment workflow] * xref:../../rosa_install_access_delete_clusters/rosa_getting_started_iam/rosa-deleting-cluster.adoc#rosa-deleting-cluster[Deleting a ROSA cluster] -* xref:../../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-architecture-models[ROSA architecture] +* xref:../../architecture/rosa-architecture-models.adoc#rosa-architecture-models[ROSA architecture models] diff --git a/welcome/about-hcp.adoc b/welcome/about-hcp.adoc index cb3c28d6b3..4cf1404a46 100644 --- a/welcome/about-hcp.adoc +++ b/welcome/about-hcp.adoc @@ -30,11 +30,11 @@ Use the following sections to find content to help you learn about and use {hcp- |=== | Learn about {hcp-title} |Plan {hcp-title} deployment |Additional resources -| xref:../rosa_architecture/rosa_architecture_sub/rosa-basic-architecture-concepts.adoc#rosa-basic-architecture-concepts[ROSA architecture concepts] +| xref:../architecture/index.adoc#architecture-overview[Architecture overview] | xref:../rosa_backing_up_and_restoring_applications/backing-up-applications.adoc#rosa-backing-up-applications[Back up and restore] | xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-life-cycle.adoc#rosa-hcp-life-cycle[{hcp-title} life cycle] -| xref:../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-architecture-models[{hcp-title} architecture] +| xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[{hcp-title} architecture] | | xref:../rosa_architecture/rosa_policy_service_definition/rosa-hcp-service-definition.adoc#rosa-hcp-service-definition[{hcp-title} service definition] @@ -51,7 +51,7 @@ Use the following sections to find content to help you learn about and use {hcp- |=== |Learn about {hcp-title} |Deploy {hcp-title} |Manage {hcp-title} |Additional resources -| xref:../rosa_architecture/rosa_architecture_sub/rosa-architecture-models.adoc#rosa-architecture-models[{hcp-title} architecture] +| xref:../architecture/rosa-architecture-models.adoc#rosa-architecture-models[{hcp-title} architecture] | xref:../rosa_hcp/rosa-hcp-sts-creating-a-cluster-quickly.adoc#rosa-hcp-sts-creating-a-cluster-quickly[Installing {hcp-title}] | xref:../logging/cluster-logging.adoc#cluster-logging[Logging] | xref:../support/index.adoc#support-overview[Getting Support] @@ -97,4 +97,4 @@ Use the following sections to find content to help you learn about and use {hcp- | xref:../cli_reference/odo-important-update.adoc#odo-important_update[Developer-focused CLI] | -|=== \ No newline at end of file +|===