diff --git a/modules/about-etcd-encryption.adoc b/modules/about-etcd-encryption.adoc index fc4af27588d9..f3e8b113fe16 100644 --- a/modules/about-etcd-encryption.adoc +++ b/modules/about-etcd-encryption.adoc @@ -7,7 +7,8 @@ [id="about-etcd_{context}"] = About etcd encryption -By default, etcd data is not encrypted in {product-title}. You can enable etcd encryption for your cluster to provide an additional layer of data security. For example, it can help protect the loss of sensitive data if an etcd backup is exposed to the incorrect parties. +[role="_abstract"] +By default, etcd data is not encrypted in {product-title}. You can enable etcd encryption for your cluster to provide an additional layer of data security. When you enable etcd encryption, the following OpenShift API server and Kubernetes API server resources are encrypted: diff --git a/modules/authentication-kubeadmin.adoc b/modules/authentication-kubeadmin.adoc index 63b3bbf225a6..0240f3f75902 100644 --- a/modules/authentication-kubeadmin.adoc +++ b/modules/authentication-kubeadmin.adoc @@ -7,8 +7,8 @@ [id="understanding-kubeadmin_{context}"] = The kubeadmin user -{product-title} creates a cluster administrator, `kubeadmin`, after the -installation process completes. +[role="_abstract"] +{product-title} creates a cluster administrator, `kubeadmin`, after the installation process completes with the `cluster-admin` role automatically applied. This user has the `cluster-admin` role automatically applied and is treated as the root user for the cluster. The password is dynamically generated diff --git a/modules/authentication-remove-kubeadmin.adoc b/modules/authentication-remove-kubeadmin.adoc index 5665036f4e03..3c488d333511 100644 --- a/modules/authentication-remove-kubeadmin.adoc +++ b/modules/authentication-remove-kubeadmin.adoc @@ -8,8 +8,8 @@ [id="removing-kubeadmin_{context}"] = Removing the kubeadmin user -After you define an identity provider and create a new `cluster-admin` -user, you can remove the `kubeadmin` to improve cluster security. +[role="_abstract"] +You can remove the `kubeadmin` user after you define an identity provider and create a new `cluster-admin` user to improve cluster security. [WARNING] ==== diff --git a/modules/binding-infra-node-workloads-using-taints-tolerations.adoc b/modules/binding-infra-node-workloads-using-taints-tolerations.adoc index 99beddac3f3e..cd952173a777 100644 --- a/modules/binding-infra-node-workloads-using-taints-tolerations.adoc +++ b/modules/binding-infra-node-workloads-using-taints-tolerations.adoc @@ -7,6 +7,9 @@ [id="binding-infra-node-workloads-using-taints-tolerations_{context}"] = Binding infrastructure node workloads using taints and tolerations +[role="_abstract"] +You can configure an infrastructure node with `infra` and `worker` roles so that user workloads are not assigned to it by using taints and tolerations. + If you have an infrastructure node that has the `infra` and `worker` roles assigned, you must configure the node so that user workloads are not assigned to it. [IMPORTANT] diff --git a/modules/cco-ccoctl-configuring.adoc b/modules/cco-ccoctl-configuring.adoc index f663343aed78..1fae7c3beb65 100644 --- a/modules/cco-ccoctl-configuring.adoc +++ b/modules/cco-ccoctl-configuring.adoc @@ -121,8 +121,12 @@ endif::[] :_mod-docs-content-type: PROCEDURE [id="cco-ccoctl-configuring_{context}"] -ifndef::update[= Configuring the Cloud Credential Operator utility] -ifdef::update[= Configuring the Cloud Credential Operator utility for a cluster update] +ifeval::["{context}" != "preparing-manual-creds-update"] += Configuring the Cloud Credential Operator utility +endif::[] +ifeval::["{context}" == "preparing-manual-creds-update"] += Configuring the Cloud Credential Operator utility for a cluster update +endif::[] [role="_abstract"] //Nutanix-only intro because it needs context in its install procedure. diff --git a/modules/cco-ccoctl-install-verifying.adoc b/modules/cco-ccoctl-install-verifying.adoc index 415eaa96225c..4fa0e1f49fa2 100644 --- a/modules/cco-ccoctl-install-verifying.adoc +++ b/modules/cco-ccoctl-install-verifying.adoc @@ -7,6 +7,7 @@ [id="cco-ccoctl-install-verifying_{context}"] = Verifying that a cluster uses short-term credentials +[role="_abstract"] You can verify that a cluster uses short-term security credentials for individual components by checking the Cloud Credential Operator (CCO) configuration and other values in the cluster. .Prerequisites diff --git a/modules/configuring-private-storage-endpoint-azure-user-provided-vnet-subnet.adoc b/modules/configuring-private-storage-endpoint-azure-user-provided-vnet-subnet.adoc index ccfa5573ba4f..64164d8b41ee 100644 --- a/modules/configuring-private-storage-endpoint-azure-user-provided-vnet-subnet.adoc +++ b/modules/configuring-private-storage-endpoint-azure-user-provided-vnet-subnet.adoc @@ -6,7 +6,8 @@ [id="configuring-private-storage-endpoint-azure-user-provided-vnet-subnet_{context}"] = Configuring a private storage endpoint on Azure with user-provided VNet and subnet names -Use the following procedure to configure a storage account that has public network access disabled and is exposed behind a private storage endpoint on Azure. +[role="_abstract"] +Use this procedure to configure an Azure storage account with public network access disabled behind a private storage endpoint using user-provided VNet and subnet names. .Prerequisites diff --git a/modules/configuring-private-storage-endpoint-azure-vnet-subnet-iro-discovery.adoc b/modules/configuring-private-storage-endpoint-azure-vnet-subnet-iro-discovery.adoc index d7580e410e5b..89cab0692eba 100644 --- a/modules/configuring-private-storage-endpoint-azure-vnet-subnet-iro-discovery.adoc +++ b/modules/configuring-private-storage-endpoint-azure-vnet-subnet-iro-discovery.adoc @@ -6,7 +6,8 @@ [id="configuring-private-storage-endpoint-azure-vnet-subnet-iro-discovery_{context}"] = Configuring a private storage endpoint on Azure by enabling the Image Registry Operator to discover VNet and subnet names -The following procedure shows you how to set up a private storage endpoint on Azure by configuring the Image Registry Operator to discover VNet and subnet names. +[role="_abstract"] +You can set up a private storage endpoint on Azure by configuring the Image Registry Operator to discover VNet and subnet names. .Prerequisites diff --git a/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc b/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc index b9f1a1d143d9..8fd00f40e36e 100644 --- a/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc +++ b/modules/create-a-kubeletconfig-crd-to-edit-kubelet-parameters.adoc @@ -7,7 +7,8 @@ [id="create-a-kubeletconfig-crd-to-edit-kubelet-parameters_{context}"] = Creating a KubeletConfig CR to edit kubelet parameters -The kubelet configuration is currently serialized as an Ignition configuration, so it can be directly edited. However, there is also a new `kubelet-config-controller` added to the Machine Config Controller (MCC). This lets you use a `KubeletConfig` custom resource (CR) to edit the kubelet parameters. +[role="_abstract"] +You can use a `KubeletConfig` custom resource (CR) to edit kubelet parameters instead of directly editing the serialized Ignition configuration. [NOTE] ==== diff --git a/modules/creating-infra-machines.adoc b/modules/creating-infra-machines.adoc index ac03ef41e969..f23128cf79e3 100644 --- a/modules/creating-infra-machines.adoc +++ b/modules/creating-infra-machines.adoc @@ -7,6 +7,9 @@ [id="creating-infra-machines_{context}"] = Creating a machine config pool for infrastructure machines +[role="_abstract"] +You can create a machine config pool for infrastructure machines when they require dedicated configurations. + If you need infrastructure machines to have dedicated configurations, you must create an infra pool. [IMPORTANT] diff --git a/modules/deploy-red-hat-openshift-container-storage.adoc b/modules/deploy-red-hat-openshift-container-storage.adoc index 152e79531580..696872720c16 100644 --- a/modules/deploy-red-hat-openshift-container-storage.adoc +++ b/modules/deploy-red-hat-openshift-container-storage.adoc @@ -3,6 +3,12 @@ // * post_installation_configuration/storage-configuration.adoc :_mod-docs-content-type: REFERENCE +[id="deploy-red-hat-openshift-container-storage_{context}"] += {rh-storage-first} documentation resources + +[role="_abstract"] +This reference table links to {rh-storage-first} documentation for deployment, management, and troubleshooting topics. + [options="header",cols="1,1"] |=== diff --git a/modules/differences-between-machinesets-and-machineconfigpool.adoc b/modules/differences-between-machinesets-and-machineconfigpool.adoc index 9c790c269c4b..28d24c4a2af8 100644 --- a/modules/differences-between-machinesets-and-machineconfigpool.adoc +++ b/modules/differences-between-machinesets-and-machineconfigpool.adoc @@ -8,7 +8,8 @@ [id="differences-between-machinesets-and-machineconfigpool_{context}"] = Understanding the difference between compute machine sets and the machine config pool -`MachineSet` objects describe {product-title} nodes with respect to the cloud or machine provider. +[role="_abstract"] +`MachineSet` objects describe {product-title} nodes with respect to the cloud or machine provider, while `MachineConfigPool` objects define how machine configuration and upgrades are applied to groups of nodes. The `MachineConfigPool` object allows `MachineConfigController` components to define and provide the status of machines in the context of upgrades. diff --git a/modules/disabling-etcd-encryption.adoc b/modules/disabling-etcd-encryption.adoc index a106d6c67799..68f4d9359610 100644 --- a/modules/disabling-etcd-encryption.adoc +++ b/modules/disabling-etcd-encryption.adoc @@ -7,6 +7,7 @@ [id="disabling-etcd-encryption_{context}"] = Disabling etcd encryption +[role="_abstract"] You can disable encryption of etcd data in your cluster. .Prerequisites diff --git a/modules/disabling-redirect-private-storage-endpoint-azure.adoc b/modules/disabling-redirect-private-storage-endpoint-azure.adoc index 2ed519b9b425..231b112fe1ac 100644 --- a/modules/disabling-redirect-private-storage-endpoint-azure.adoc +++ b/modules/disabling-redirect-private-storage-endpoint-azure.adoc @@ -6,6 +6,9 @@ [id="disabling-redirect-private-storage-endpoint-azure_{context}"] = Optional: Disabling redirect when using a private storage endpoint on Azure +[role="_abstract"] +You can disable redirect when using a private storage endpoint on Azure so that users outside the cluster can pull images from the registry. + By default, redirect is enabled when using the image registry. Redirect allows off-loading of traffic from the registry pods into the object storage, which makes pull faster. When redirect is enabled and the storage account is private, users from outside of the cluster are unable to pull images from the registry. In some cases, users might want to disable redirect so that users from outside of the cluster can pull images from the registry. diff --git a/modules/dr-restoring-cluster-state.adoc b/modules/dr-restoring-cluster-state.adoc index d251ef232e28..865cb06db2e9 100644 --- a/modules/dr-restoring-cluster-state.adoc +++ b/modules/dr-restoring-cluster-state.adoc @@ -17,7 +17,7 @@ [id="dr-scenario-2-restoring-cluster-state_{context}"] = Restoring to an earlier cluster state for more than one node -[role="abstract"] +[role="_abstract"] You can use a saved etcd backup to restore an earlier cluster state or restore a cluster that has lost the majority of control plane hosts. For a Two-Node with Fencing (TNF) setup, a single surviving node can continue to operate in degraded mode. Use a saved etcd backup to restore an earlier cluster state if only one node is operational, or when both nodes have failed and you need to restart the cluster from a known safe state. In both cases, perform the restore procedure on a single node. The peer node automatically synchronizes its data with the restored node when it rejoins the cluster. diff --git a/modules/dr-scenario-cluster-state-issues.adoc b/modules/dr-scenario-cluster-state-issues.adoc index 9db2a9d1ffea..ba230622b431 100644 --- a/modules/dr-scenario-cluster-state-issues.adoc +++ b/modules/dr-scenario-cluster-state-issues.adoc @@ -8,7 +8,8 @@ [id="dr-scenario-cluster-state-issues_{context}"] = Issues and workarounds for restoring a persistent storage state -If your {product-title} cluster uses persistent storage of any form, a state of the cluster is typically stored outside etcd. When you restore from an etcd backup, the status of the workloads in {product-title} is also restored. However, if the etcd snapshot is old, the status might be invalid or outdated. +[role="_abstract"] +If your {product-title} cluster uses persistent storage, restoring from an etcd backup can leave workload status invalid or outdated because cluster state stored outside etcd is not fully captured in the snapshot. [IMPORTANT] ==== diff --git a/modules/enabling-etcd-encryption.adoc b/modules/enabling-etcd-encryption.adoc index c257d79df7a1..16eb413eebba 100644 --- a/modules/enabling-etcd-encryption.adoc +++ b/modules/enabling-etcd-encryption.adoc @@ -7,6 +7,7 @@ [id="enabling-etcd-encryption_{context}"] = Enabling etcd encryption +[role="_abstract"] You can enable etcd encryption to encrypt sensitive resources in your cluster. [WARNING] diff --git a/modules/etcd-defrag.adoc b/modules/etcd-defrag.adoc index af8b08fed106..a6c4f136a9b1 100644 --- a/modules/etcd-defrag.adoc +++ b/modules/etcd-defrag.adoc @@ -7,6 +7,9 @@ [id="etcd-defrag_{context}"] = Defragmenting etcd data +[role="_abstract"] +You can defragment etcd data to free up space when the keyspace grows too large and affects cluster performance. + For large and dense clusters, etcd can suffer from poor performance if the keyspace grows too large and exceeds the space quota. Periodically maintain and defragment etcd to free up space in the data store. Monitor Prometheus for etcd metrics and defragment it when required; otherwise, etcd can raise a cluster-wide alarm that puts the cluster into a maintenance mode that accepts only key reads and deletes. Monitor these key metrics: diff --git a/modules/etcd-encryption-types.adoc b/modules/etcd-encryption-types.adoc index 56754af20a76..b510b96bb6ae 100644 --- a/modules/etcd-encryption-types.adoc +++ b/modules/etcd-encryption-types.adoc @@ -7,6 +7,9 @@ [id="etcd-encryption-types_{context}"] = Supported encryption types +[role="_abstract"] +The following encryption types are supported for encrypting etcd data in {product-title}: AES-CBC and AES-GCM. + The following encryption types are supported for encrypting etcd data in {product-title}: AES-CBC:: Uses AES-CBC with PKCS#7 padding and a 32 byte key to perform the encryption. diff --git a/modules/identity-provider-default-CR.adoc b/modules/identity-provider-default-CR.adoc index a7363bbfd982..4686be320631 100644 --- a/modules/identity-provider-default-CR.adoc +++ b/modules/identity-provider-default-CR.adoc @@ -7,9 +7,8 @@ [id="identity-provider-default-CR_{context}"] = Sample identity provider CR -The following custom resource (CR) shows the parameters and default -values that you use to configure an identity provider. This example -uses the htpasswd identity provider. +[role="_abstract"] +The following custom resource (CR) shows the parameters and default values that you use to configure an identity provider. .Sample identity provider CR diff --git a/modules/identity-provider-overview.adoc b/modules/identity-provider-overview.adoc index 0f69f7bad451..fb9e32a24f52 100644 --- a/modules/identity-provider-overview.adoc +++ b/modules/identity-provider-overview.adoc @@ -18,9 +18,8 @@ [id="identity-provider-overview_{context}"] = About identity providers in {product-title} -By default, only a `kubeadmin` user exists on your cluster. To specify an -identity provider, you must create a custom resource (CR) that describes -that identity provider and add it to the cluster. +[role="_abstract"] +By default, only a `kubeadmin` user exists on your cluster. To specify an identity provider, you must create a custom resource (CR) that describes that identity provider and add it to the cluster. [NOTE] ==== diff --git a/modules/images-cluster-sample-imagestream-import.adoc b/modules/images-cluster-sample-imagestream-import.adoc index 2fe8dd38b1b0..4e41621ec83e 100644 --- a/modules/images-cluster-sample-imagestream-import.adoc +++ b/modules/images-cluster-sample-imagestream-import.adoc @@ -5,7 +5,8 @@ [id="images-cluster-sample-imagestream-import_{context}"] = Configuring periodic importing of Cluster Sample Operator image stream tags -You can ensure that you always have access to the latest versions of the Cluster Sample Operator images by periodically importing the image stream tags when new versions become available. +[role="_abstract"] +You can ensure access to the latest Cluster Sample Operator images by periodically importing image stream tags when new versions become available. .Procedure diff --git a/modules/infrastructure-moving-monitoring.adoc b/modules/infrastructure-moving-monitoring.adoc index ad002b689082..d92d6530e156 100644 --- a/modules/infrastructure-moving-monitoring.adoc +++ b/modules/infrastructure-moving-monitoring.adoc @@ -6,8 +6,10 @@ [id="infrastructure-moving-monitoring_{context}"] = Moving the monitoring solution +[role="_abstract"] +You can redeploy the monitoring stack to infrastructure nodes by creating and applying a custom config map. + The monitoring stack includes multiple components, including Prometheus, Thanos Querier, and Alertmanager. -The {cmo-full} manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map. .Prerequisites diff --git a/modules/infrastructure-moving-registry.adoc b/modules/infrastructure-moving-registry.adoc index 5669bafb0e7e..c4180fc8b292 100644 --- a/modules/infrastructure-moving-registry.adoc +++ b/modules/infrastructure-moving-registry.adoc @@ -6,7 +6,8 @@ [id="infrastructure-moving-registry_{context}"] = Moving the default registry -You configure the registry Operator to deploy its pods to different nodes. +[role="_abstract"] +You can configure the registry Operator to deploy its pods to different nodes. .Prerequisites diff --git a/modules/infrastructure-moving-router.adoc b/modules/infrastructure-moving-router.adoc index 8bac5a407cc2..240d6270c215 100644 --- a/modules/infrastructure-moving-router.adoc +++ b/modules/infrastructure-moving-router.adoc @@ -6,7 +6,8 @@ [id="infrastructure-moving-router_{context}"] = Moving the router -You can deploy the router pod to a different compute machine set. By default, the pod is deployed to a worker node. +[role="_abstract"] +You can deploy the router pod to a different compute machine set. .Prerequisites diff --git a/modules/installation-preparing-restricted-cluster-to-gather-support-data.adoc b/modules/installation-preparing-restricted-cluster-to-gather-support-data.adoc index 05e27faadf94..71e5a1e0291a 100644 --- a/modules/installation-preparing-restricted-cluster-to-gather-support-data.adoc +++ b/modules/installation-preparing-restricted-cluster-to-gather-support-data.adoc @@ -6,7 +6,8 @@ [id="installation-preparing-restricted-cluster-to-gather-support-data_{context}"] = Preparing your cluster to gather support data -Clusters using a restricted network must import the default must-gather image to gather debugging data for Red Hat support. The must-gather image is not imported by default, and clusters on a restricted network do not have access to the internet to pull the latest image from a remote repository. +[role="_abstract"] +You can import the default must-gather image on a restricted network cluster so that you can gather debugging data for Red Hat support. .Procedure diff --git a/modules/machine-health-checks-about.adoc b/modules/machine-health-checks-about.adoc index 00067a848118..72143f524fe0 100644 --- a/modules/machine-health-checks-about.adoc +++ b/modules/machine-health-checks-about.adoc @@ -7,6 +7,9 @@ [id="machine-health-checks-about_{context}"] = About machine health checks +[role="_abstract"] +Machine health checks monitor machine health by observing defined conditions and automatically replacing unhealthy machines managed by compute machine sets or control plane machine sets. + [NOTE] ==== You can only apply a machine health check to machines that are managed by compute machine sets or control plane machine sets. diff --git a/modules/machine-health-checks-creating.adoc b/modules/machine-health-checks-creating.adoc index 79e51bbd8912..d65a4109bf2e 100644 --- a/modules/machine-health-checks-creating.adoc +++ b/modules/machine-health-checks-creating.adoc @@ -7,6 +7,7 @@ [id="machine-health-checks-creating_{context}"] = Creating a machine health check resource +[role="_abstract"] You can create a `MachineHealthCheck` resource for machine sets in your cluster. [NOTE] diff --git a/modules/machine-health-checks-resource.adoc b/modules/machine-health-checks-resource.adoc index 6832ba038eed..d9c6dc00d7fb 100644 --- a/modules/machine-health-checks-resource.adoc +++ b/modules/machine-health-checks-resource.adoc @@ -7,7 +7,8 @@ [id="machine-health-checks-resource_{context}"] = Sample MachineHealthCheck resource -The `MachineHealthCheck` resource for all cloud-based installation types, and other than bare metal, resembles the following YAML file: +[role="_abstract"] +The `MachineHealthCheck` resource defines the configuration for monitoring machine health on cloud-based installation types and platforms other than bare metal. [source,yaml] ---- diff --git a/modules/machine-node-custom-partition.adoc b/modules/machine-node-custom-partition.adoc index a70241ac46ad..d7e86fce3d56 100644 --- a/modules/machine-node-custom-partition.adoc +++ b/modules/machine-node-custom-partition.adoc @@ -8,6 +8,9 @@ [id="machine-node-custom-partition_{context}"] = Adding a new {op-system} worker node with a custom `/var` partition in AWS +[role="_abstract"] +You can add a new {op-system-first} compute node with a custom `/var` partition when the instance uses a different device name from what was configured at installation. + {product-title} supports partitioning devices during installation by using machine configs that are processed during the bootstrap. However, if you use `/var` partitioning, the device name must be determined at installation and cannot be changed. You cannot add different instance types as nodes if they have a different device naming schema. For example, if you configured the `/var` partition with the default AWS device name for `m4.large` instances, `dev/xvdb`, you cannot directly add an AWS `m5.large` instance, as `m5.large` instances use a `/dev/nvme1n1` device by default. The device might fail to partition due to the different naming schema. The procedure in this section shows how to add a new {op-system-first} compute node with an instance that uses a different device name from what was configured at installation. You create a custom user data secret and configure a new compute machine set. These steps are specific to an AWS cluster. The principles apply to other cloud deployments also. However, the device naming schema is different for other deployments and should be determined on a per-case basis. diff --git a/modules/machineset-delete-policy.adoc b/modules/machineset-delete-policy.adoc index b68cbef9e1f7..8bf22f6244d9 100644 --- a/modules/machineset-delete-policy.adoc +++ b/modules/machineset-delete-policy.adoc @@ -7,7 +7,8 @@ [id="machineset-delete-policy_{context}"] = The compute machine set deletion policy -`Random`, `Newest`, and `Oldest` are the three supported deletion options. The default is `Random`, meaning that random machines are chosen and deleted when scaling compute machine sets down. The deletion policy can be set according to the use case by modifying the particular compute machine set: +[role="_abstract"] +`Random`, `Newest`, and `Oldest` are the three supported deletion options for scaling compute machine sets down. [source,yaml] ---- diff --git a/modules/manually-removing-cloud-creds.adoc b/modules/manually-removing-cloud-creds.adoc index 76be9313ca56..c5292497a10f 100644 --- a/modules/manually-removing-cloud-creds.adoc +++ b/modules/manually-removing-cloud-creds.adoc @@ -6,7 +6,10 @@ [id="manually-removing-cloud-creds_{context}"] = Removing cloud provider credentials -For clusters that use the Cloud Credential Operator (CCO) in mint mode, the administrator-level credential is stored in the `kube-system` namespace. +[role="_abstract"] +You can remove the administrator-level cloud provider credential secret from a cluster that uses the Cloud Credential Operator (CCO) in mint mode after initial installation. + +For clusters that use the Cloud Credential Operator (CCO) in mint mode, the administrator-level credential is stored in the `kube-system` namespace. The CCO uses the `admin` credential to process the `CredentialsRequest` objects in the cluster and create users for components with limited permissions. After installing an {product-title} cluster with the CCO in mint mode, you can remove the administrator-level credential secret from the `kube-system` namespace in the cluster. diff --git a/modules/manually-rotating-cloud-creds.adoc b/modules/manually-rotating-cloud-creds.adoc index 0ee8829c23af..115e4776649e 100644 --- a/modules/manually-rotating-cloud-creds.adoc +++ b/modules/manually-rotating-cloud-creds.adoc @@ -16,8 +16,15 @@ endif::[] :_mod-docs-content-type: PROCEDURE [id="manually-rotating-cloud-creds_{context}"] -ifdef::post-install[= Rotating cloud provider credentials manually] -ifndef::post-install[= Maintaining cloud provider credentials] +ifeval::["{context}" == "changing-cloud-credentials-configuration"] += Rotating cloud provider credentials manually +endif::[] +ifeval::["{context}" != "changing-cloud-credentials-configuration"] += Maintaining cloud provider credentials +endif::[] + +[role="_abstract"] +You can manually update the secret that the Cloud Credential Operator (CCO) uses when cloud provider credentials change. If your cloud provider credentials are changed for any reason, you must manually update the secret that the Cloud Credential Operator (CCO) uses to manage cloud provider credentials. diff --git a/modules/modify-unavailable-workers.adoc b/modules/modify-unavailable-workers.adoc index 92816d570891..68a791b258b7 100644 --- a/modules/modify-unavailable-workers.adoc +++ b/modules/modify-unavailable-workers.adoc @@ -6,7 +6,8 @@ [id="modify-unavailable-workers_{context}"] = Modifying the number of unavailable worker nodes -By default, only one machine is allowed to be unavailable when applying the kubelet-related configuration to the available worker nodes. For a large cluster, it can take a long time for the configuration change to be reflected. At any time, you can adjust the number of machines that are updating to speed up the process. +[role="_abstract"] +You can adjust the number of unavailable worker nodes during kubelet configuration updates to speed up the process on large clusters. .Procedure diff --git a/modules/monitoring-sending-notifications-to-external-systems.adoc b/modules/monitoring-sending-notifications-to-external-systems.adoc index b3af7fb0511c..9e8e81939da6 100644 --- a/modules/monitoring-sending-notifications-to-external-systems.adoc +++ b/modules/monitoring-sending-notifications-to-external-systems.adoc @@ -7,6 +7,9 @@ [id="sending-notifications-to-external-systems_{context}"] = Sending notifications to external systems +[role="_abstract"] +In {product-title}, firing alerts can be viewed in the Alerting UI, but alerts are not configured by default to be sent to notification systems. You can configure {product-title} to send alerts to external receiver types. + In {product-title} ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] {product-version} diff --git a/modules/nodes-pods-plugins-about.adoc b/modules/nodes-pods-plugins-about.adoc index a370817517de..f90adda70f78 100644 --- a/modules/nodes-pods-plugins-about.adoc +++ b/modules/nodes-pods-plugins-about.adoc @@ -7,10 +7,8 @@ [id="nodes-pods-plugins-about_{context}"] = Understanding device plugins -The device plugin provides a consistent and portable solution to consume hardware -devices across clusters. The device plugin provides support for these devices -through an extension mechanism, which makes these devices available to -Containers, provides health checks of these devices, and securely shares them. +[role="_abstract"] +The device plugin provides a consistent and portable solution to consume hardware devices across clusters through an extension mechanism. [IMPORTANT] ==== diff --git a/modules/nodes-pods-plugins-device-mgr.adoc b/modules/nodes-pods-plugins-device-mgr.adoc index 602f49bb89f0..94e8fa2b7ed0 100644 --- a/modules/nodes-pods-plugins-device-mgr.adoc +++ b/modules/nodes-pods-plugins-device-mgr.adoc @@ -7,8 +7,8 @@ [id="nodes-pods-plugins-device-mgr_{context}"] = Understanding the Device Manager -Device Manager provides a mechanism for advertising specialized node hardware resources -with the help of plugins known as device plugins. +[role="_abstract"] +Device Manager provides a mechanism for advertising specialized node hardware resources with the help of device plugins. You can advertise specialized hardware without requiring any upstream code changes. diff --git a/modules/nodes-pods-plugins-install.adoc b/modules/nodes-pods-plugins-install.adoc index 239f89d1ebd6..2c5fdf2b487f 100644 --- a/modules/nodes-pods-plugins-install.adoc +++ b/modules/nodes-pods-plugins-install.adoc @@ -7,6 +7,9 @@ [id="nodes-pods-plugins-install_{context}"] = Enabling Device Manager +[role="_abstract"] +You can enable Device Manager to implement a device plugin that advertises specialized hardware without upstream code changes. + Enable Device Manager to implement a device plugin to advertise specialized hardware without any upstream code changes. diff --git a/modules/nodes-vsphere-machine-set-concept-static-ip.adoc b/modules/nodes-vsphere-machine-set-concept-static-ip.adoc index 4ccf7961a3a3..7c7be8d77f79 100644 --- a/modules/nodes-vsphere-machine-set-concept-static-ip.adoc +++ b/modules/nodes-vsphere-machine-set-concept-static-ip.adoc @@ -6,7 +6,8 @@ [id="nodes-vsphere-machine-set-concept-static-ip_{context}"] = Machine set scaling of machines with configured static IP addresses -You can use a machine set to scale machines with configured static IP addresses. +[role="_abstract"] +You can use a machine set to scale machines with configured static IP addresses on {product-title}. After you configure a machine set to request a static IP address for a machine, the machine controller creates an `IPAddressClaim` resource in the `openshift-machine-api` namespace. The external controller then creates an `IPAddress` resource and binds any static IP addresses to the `IPAddressClaim` resource. diff --git a/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc b/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc index 24800dd49a74..99292247b9fb 100644 --- a/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc +++ b/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc @@ -6,6 +6,7 @@ [id="nodes-vsphere-machine-set-scaling-static-ip_{context}"] = Using a machine set to scale machines with configured static IP addresses +[role="_abstract"] You can use a machine set to scale machines with configured static IP addresses. The example in the procedure demonstrates the use of controllers for scaling machines in a machine set. diff --git a/modules/nodes-vsphere-scaling-machines-static-ip.adoc b/modules/nodes-vsphere-scaling-machines-static-ip.adoc index 5d08984fc3c7..802cacddc7f4 100644 --- a/modules/nodes-vsphere-scaling-machines-static-ip.adoc +++ b/modules/nodes-vsphere-scaling-machines-static-ip.adoc @@ -6,7 +6,8 @@ [id="nodes-vsphere-scaling-machines-static-ip_{context}"] = Scaling machines to use static IP addresses -You can scale additional machine sets to use pre-defined static IP addresses on your cluster. For this configuration, you need to create a machine resource YAML file and then define static IP addresses in this file. +[role="_abstract"] +You can scale additional machine sets to use pre-defined static IP addresses by creating a machine resource YAML file. .Prerequisites diff --git a/modules/olm-creating-catalog-from-index.adoc b/modules/olm-creating-catalog-from-index.adoc index cd74a1603fac..0d82c6c605a1 100644 --- a/modules/olm-creating-catalog-from-index.adoc +++ b/modules/olm-creating-catalog-from-index.adoc @@ -25,7 +25,9 @@ endif::[] [id="olm-creating-catalog-from-index_{context}"] = Adding a catalog source to a cluster -Adding a catalog source to an {product-title} cluster enables the discovery and installation of Operators for users. +[role="_abstract"] +You can add a catalog source to an {product-title} cluster to enable the discovery and installation of Operators for users. + ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] Cluster administrators endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] diff --git a/modules/olm-installing-from-software-catalog-using-cli.adoc b/modules/olm-installing-from-software-catalog-using-cli.adoc index e851cb6adfcd..e821d4c8eeae 100644 --- a/modules/olm-installing-from-software-catalog-using-cli.adoc +++ b/modules/olm-installing-from-software-catalog-using-cli.adoc @@ -16,7 +16,8 @@ endif::[] [id="olm-installing-operator-from-software-catalog-using-cli_{context}"] = Installing from the software catalog by using the CLI -Instead of using the {product-title} web console, you can install an Operator from the software catalog by using the CLI. Use the `oc` command to create or update a `Subscription` object. +[role="_abstract"] +You can install an Operator from the software catalog by using the CLI to create or update a `Subscription` object. For `SingleNamespace` install mode, you must also ensure an appropriate Operator group exists in the related namespace. An Operator group, defined by an `OperatorGroup` object, selects target namespaces in which to generate required RBAC access for all Operators in the same namespace as the Operator group. diff --git a/modules/olm-installing-from-software-catalog-using-web-console.adoc b/modules/olm-installing-from-software-catalog-using-web-console.adoc index 5f4bcd35c23c..f88ca94197f9 100644 --- a/modules/olm-installing-from-software-catalog-using-web-console.adoc +++ b/modules/olm-installing-from-software-catalog-using-web-console.adoc @@ -33,7 +33,8 @@ endif::[] [id="olm-installing-from-software-catalog-using-web-console_{context}"] = Installing from the software catalog by using the web console -You can install and subscribe to an Operator from software catalog by using the {product-title} web console. +[role="_abstract"] +You can install and subscribe to an Operator from the software catalog by using the {product-title} web console. .Prerequisites diff --git a/modules/olm-installing-operators-from-software-catalog-configure.adoc b/modules/olm-installing-operators-from-software-catalog-configure.adoc index 8fc016f037df..11edbcfc1e89 100644 --- a/modules/olm-installing-operators-from-software-catalog-configure.adoc +++ b/modules/olm-installing-operators-from-software-catalog-configure.adoc @@ -10,8 +10,9 @@ [id="olm-installing-operators-from-software-catalog-configure_{context}"] = About Operator Catalogs in {product-title} -Out of the box {product-title} provides a catalog source for community operators. -These operators are built and distributed by the community. +[role="_abstract"] +Out of the box {product-title} provides a catalog source for community operators built and distributed by the community. + There are ongoing efforts to make more operators available through a community operator catalog. Please note that the Red Hat Operators catalog is not available in {product-title}. According to the subscription agreement, these operators can be used only on OpenShift Container Platform clusters. diff --git a/modules/olm-installing-operators-from-software-catalog.adoc b/modules/olm-installing-operators-from-software-catalog.adoc index f6907157689f..700255c628c0 100644 --- a/modules/olm-installing-operators-from-software-catalog.adoc +++ b/modules/olm-installing-operators-from-software-catalog.adoc @@ -16,6 +16,7 @@ endif::[] [id="olm-installing-operators-from-software-catalog_{context}"] = About Operator installation from the software catalog +[role="_abstract"] The software catalog is a user interface for discovering Operators; it works in conjunction with Operator Lifecycle Manager (OLM), which installs and manages Operators on a cluster. ifndef::olm-user,openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] diff --git a/modules/olm-mirroring-catalog-icsp.adoc b/modules/olm-mirroring-catalog-icsp.adoc index ff149dc7425e..cb56b838097c 100644 --- a/modules/olm-mirroring-catalog-icsp.adoc +++ b/modules/olm-mirroring-catalog-icsp.adoc @@ -6,7 +6,8 @@ [id="olm-mirror-catalog-icsp_{context}"] = Creating the ImageContentSourcePolicy object -After mirroring Operator catalog content to your mirror registry, create the required `ImageContentSourcePolicy` (ICSP) object. The ICSP object configures nodes to translate between the image references stored in Operator manifests and the mirrored registry. +[role="_abstract"] +You can create an `ImageContentSourcePolicy` (ICSP) object to configure nodes to translate between image references in Operator manifests and your mirrored registry. .Procedure diff --git a/modules/private-clusters-about.adoc b/modules/private-clusters-about.adoc index b289b4659fcc..6ed25eec731c 100644 --- a/modules/private-clusters-about.adoc +++ b/modules/private-clusters-about.adoc @@ -6,7 +6,7 @@ [id="private-clusters-about_{context}"] = About private clusters - +[role="_abstract"] By default, {product-title} is provisioned using publicly-accessible DNS and endpoints. You can set the DNS, Ingress Controller, and API server to private after you deploy your private cluster. include::snippets/snip-private-clusters-public-ingress.adoc[] diff --git a/modules/private-clusters-setting-dns-private.adoc b/modules/private-clusters-setting-dns-private.adoc index f0ab7577db32..f997f826d5e9 100644 --- a/modules/private-clusters-setting-dns-private.adoc +++ b/modules/private-clusters-setting-dns-private.adoc @@ -6,6 +6,9 @@ [id="private-clusters-setting-dns-private_{context}"] = Configuring DNS records to be published in a private zone +[role="_abstract"] +You can remove the public zone from the cluster DNS configuration to publish DNS records only in a private zone. + For all {product-title} clusters, whether public or private, DNS records are published in a public zone by default. You can remove the public zone from the cluster DNS configuration to avoid exposing DNS records to the public. You might want to avoid exposing sensitive information, such as internal domain names, internal IP addresses, or the number of clusters at an organization, or you might simply have no need to publish records publicly. If all the clients that should be able to connect to services within the cluster use a private DNS service that has the DNS records from the private zone, then there is no need to have a public DNS record for the cluster. diff --git a/modules/private-clusters-setting-ingress-private.adoc b/modules/private-clusters-setting-ingress-private.adoc index f16e15754908..59d39c1cd885 100644 --- a/modules/private-clusters-setting-ingress-private.adoc +++ b/modules/private-clusters-setting-ingress-private.adoc @@ -6,7 +6,8 @@ [id="private-clusters-setting-ingress-private_{context}"] = Setting the Ingress Controller to private -After you deploy a cluster, you can modify its Ingress Controller to use only a private zone. +[role="_abstract"] +You can modify the Ingress Controller after deployment to use only a private zone. .Procedure diff --git a/modules/rbac-adding-roles.adoc b/modules/rbac-adding-roles.adoc index 5d480b26ca89..4ac2d2975875 100644 --- a/modules/rbac-adding-roles.adoc +++ b/modules/rbac-adding-roles.adoc @@ -7,7 +7,8 @@ [id="adding-roles_{context}"] = Adding roles to users -You can use the `oc adm` administrator CLI to manage the roles and bindings. +[role="_abstract"] +You can use the `oc adm` administrator CLI to add and remove roles for users and groups. Binding, or adding, a role to users or groups gives the user or group the access that is granted by the role. You can add and remove roles to and from users and diff --git a/modules/rbac-cluster-role-binding-commands.adoc b/modules/rbac-cluster-role-binding-commands.adoc index 20f6ec384df6..55f9939f70c6 100644 --- a/modules/rbac-cluster-role-binding-commands.adoc +++ b/modules/rbac-cluster-role-binding-commands.adoc @@ -3,14 +3,15 @@ // * authentication/using-rbac.adoc // * post_installation_configuration/preparing-for-users.adoc +:_mod-docs-content-type: REFERENCE + ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedicated,openshift-rosa[] [id="cluster-role-binding-commands_{context}"] = Cluster role binding commands -You can also manage cluster role bindings using the following -operations. The `-n` flag is not used for these operations because -cluster role bindings use non-namespaced resources. +[role="_abstract"] +You can manage cluster role bindings using CLI operations that do not require the `-n` flag because cluster role bindings use non-namespaced resources. .Cluster role binding operations [options="header"] diff --git a/modules/rbac-creating-cluster-admin.adoc b/modules/rbac-creating-cluster-admin.adoc index 654086e41076..256362b9afee 100644 --- a/modules/rbac-creating-cluster-admin.adoc +++ b/modules/rbac-creating-cluster-admin.adoc @@ -7,9 +7,8 @@ [id="creating-cluster-admin_{context}"] = Creating a cluster admin -The `cluster-admin` role is required to perform administrator -level tasks on the {product-title} cluster, such as modifying -cluster resources. +[role="_abstract"] +You can create a user with the `cluster-admin` role to perform administrator-level tasks on the {product-title} cluster. .Prerequisites diff --git a/modules/rbac-creating-cluster-role.adoc b/modules/rbac-creating-cluster-role.adoc index 77068aefc288..dc0910a847cc 100644 --- a/modules/rbac-creating-cluster-role.adoc +++ b/modules/rbac-creating-cluster-role.adoc @@ -8,7 +8,8 @@ ifdef::openshift-enterprise,openshift-webscale,openshift-origin[] [id="creating-cluster-role_{context}"] = Creating a cluster role -You can create a cluster role. +[role="_abstract"] +You can create a cluster role by using the `oc` CLI. .Procedure diff --git a/modules/rbac-creating-local-role.adoc b/modules/rbac-creating-local-role.adoc index e97ed89f7d1e..803c09963a9c 100644 --- a/modules/rbac-creating-local-role.adoc +++ b/modules/rbac-creating-local-role.adoc @@ -8,7 +8,8 @@ ifdef::openshift-enterprise,openshift-webscale,openshift-origin,openshift-dedica [id="creating-local-role_{context}"] = Creating a local role -You can create a local role for a project and then bind it to a user. +[role="_abstract"] +You can create a local role for a project and bind it to a user. .Procedure diff --git a/modules/rbac-default-projects.adoc b/modules/rbac-default-projects.adoc index 6c69566646b1..90f6dc4ea218 100644 --- a/modules/rbac-default-projects.adoc +++ b/modules/rbac-default-projects.adoc @@ -3,11 +3,13 @@ // * authentication/using-rbac.adoc // * post_installation_configuration/preparing-for-users.adoc +:_mod-docs-content-type: CONCEPT [id="rbac-default-projects_{context}"] = Default projects -{product-title} comes with a number of default projects, and projects -starting with `openshift-` are the most essential to users. +[role="_abstract"] +{product-title} includes default projects, and projects starting with `openshift-` host essential infrastructure components. + These projects host master components that run as pods and other infrastructure components. The pods created in these namespaces that have a link:https://kubernetes.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#rescheduler-guaranteed-scheduling-of-critical-add-ons[critical pod annotation] diff --git a/modules/rbac-local-role-binding-commands.adoc b/modules/rbac-local-role-binding-commands.adoc index 2801473ee7d9..0f17bb063d47 100644 --- a/modules/rbac-local-role-binding-commands.adoc +++ b/modules/rbac-local-role-binding-commands.adoc @@ -3,12 +3,12 @@ // * authentication/using-rbac.adoc // * post_installation_configuration/preparing-for-users.adoc +:_mod-docs-content-type: REFERENCE [id="local-role-binding-commands_{context}"] = Local role binding commands -When you manage a user or group's associated roles for local role bindings using the -following operations, a project may be specified with the `-n` flag. If it is -not specified, then the current project is used. +[role="_abstract"] +You can manage local role bindings for users and groups using CLI operations, optionally specifying a project with the `-n` flag. You can use the following commands for local RBAC management. diff --git a/modules/rbac-overview.adoc b/modules/rbac-overview.adoc index ac87676996df..6a9c93afac7c 100644 --- a/modules/rbac-overview.adoc +++ b/modules/rbac-overview.adoc @@ -7,8 +7,8 @@ [id="authorization-overview_{context}"] = RBAC overview -Role-based access control (RBAC) objects determine whether a user is allowed to -perform a given action within a project. +[role="_abstract"] +Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. ifdef::openshift-enterprise,openshift-webscale,openshift-origin[] Cluster administrators diff --git a/modules/rbac-projects-namespaces.adoc b/modules/rbac-projects-namespaces.adoc index ade42d4e324e..a950f37a07a2 100644 --- a/modules/rbac-projects-namespaces.adoc +++ b/modules/rbac-projects-namespaces.adoc @@ -3,9 +3,13 @@ // * authentication/using-rbac.adoc // * post_installation_configuration/preparing-for-users.adoc +:_mod-docs-content-type: CONCEPT [id="rbac-projects-namespaces_{context}"] = Projects and namespaces +[role="_abstract"] +A Kubernetes namespace provides a mechanism to scope resources in a cluster, and {product-title} projects are a wrapper around namespaces. + A Kubernetes _namespace_ provides a mechanism to scope resources in a cluster. The https://kubernetes.io/docs/tasks/administer-cluster/namespaces/[Kubernetes documentation] diff --git a/modules/rbac-viewing-cluster-roles.adoc b/modules/rbac-viewing-cluster-roles.adoc index a744f184d961..4ab9154ed0ac 100644 --- a/modules/rbac-viewing-cluster-roles.adoc +++ b/modules/rbac-viewing-cluster-roles.adoc @@ -7,8 +7,8 @@ [id="viewing-cluster-roles_{context}"] = Viewing cluster roles and bindings -You can use the `oc` CLI to view cluster roles and bindings by using the -`oc describe` command. +[role="_abstract"] +You can use the `oc` CLI to view cluster roles and bindings by using the `oc describe` command. .Prerequisites diff --git a/modules/rbac-viewing-local-roles.adoc b/modules/rbac-viewing-local-roles.adoc index e43359e5121e..f4f4e15ad66d 100644 --- a/modules/rbac-viewing-local-roles.adoc +++ b/modules/rbac-viewing-local-roles.adoc @@ -7,8 +7,8 @@ [id="viewing-local-roles_{context}"] = Viewing local roles and bindings -You can use the `oc` CLI to view local roles and bindings by using the -`oc describe` command. +[role="_abstract"] +You can use the `oc` CLI to view local roles and bindings by using the `oc describe` command. .Prerequisites diff --git a/modules/recommended-node-host-practices.adoc b/modules/recommended-node-host-practices.adoc index 847254d21d6a..6ca73fc5d63a 100644 --- a/modules/recommended-node-host-practices.adoc +++ b/modules/recommended-node-host-practices.adoc @@ -6,8 +6,7 @@ [id="recommended-node-host-practices_{context}"] = Recommended node host practices -The {product-title} node configuration file contains important options. For -example, two parameters control the maximum number of pods that can be scheduled -to a node: `podsPerCore` and `maxPods`. +[role="_abstract"] +The {product-title} node configuration file contains important options for node sizing and scheduling, including parameters that control the maximum number of pods per node. include::snippets/nodes-pods-core-max-pods.adoc[] diff --git a/modules/refreshing-service-ids-ibm-cloud.adoc b/modules/refreshing-service-ids-ibm-cloud.adoc index cb1a1c2c2d4b..f6c72639acf2 100644 --- a/modules/refreshing-service-ids-ibm-cloud.adoc +++ b/modules/refreshing-service-ids-ibm-cloud.adoc @@ -6,6 +6,7 @@ [id="refreshing-service-ids-ibm-cloud_{context}"] = Rotating {ibm-cloud-title} credentials +[role="_abstract"] You can rotate API keys for your existing service IDs and update the corresponding secrets. .Prerequisites diff --git a/modules/registry-configuring-private-storage-endpoint-azure.adoc b/modules/registry-configuring-private-storage-endpoint-azure.adoc index 9caa1f93d359..9fe2cfd4de10 100644 --- a/modules/registry-configuring-private-storage-endpoint-azure.adoc +++ b/modules/registry-configuring-private-storage-endpoint-azure.adoc @@ -6,7 +6,8 @@ [id="registry-configuring-private-storage-endpoint-azure_{context}"] = Configuring a private storage endpoint on Azure -You can leverage the Image Registry Operator to use private endpoints on Azure, which enables seamless configuration of private storage accounts when {product-title} is deployed on private Azure clusters. This allows you to deploy the image registry without exposing public-facing storage endpoints. +[role="_abstract"] +You can configure the Image Registry Operator to use private endpoints on Azure, enabling private storage accounts when {product-title} is deployed on private Azure clusters. [IMPORTANT] ==== diff --git a/modules/unauthenticated-users-cluster-role-binding-con.adoc b/modules/unauthenticated-users-cluster-role-binding-con.adoc index dc7f8468e2fb..883308cdf60a 100644 --- a/modules/unauthenticated-users-cluster-role-binding-con.adoc +++ b/modules/unauthenticated-users-cluster-role-binding-con.adoc @@ -7,13 +7,14 @@ [id="unauthenticated-users-cluster-role-bindings-concept_{context}"] = Cluster role bindings for unauthenticated groups +[role="_abstract"] +For security reasons, {product-title} {product-version} does not allow unauthenticated groups to have default access to cluster roles. + [NOTE] ==== Before {product-title} 4.17, unauthenticated groups were allowed access to some cluster roles. Clusters updated from versions before {product-title} 4.17 retain this access for unauthenticated groups. ==== -For security reasons {product-title} {product-version} does not allow unauthenticated groups to have default access to cluster roles. - There are use cases where it might be necessary to add `system:unauthenticated` to a cluster role. Cluster administrators can add unauthenticated users to the following cluster roles: diff --git a/modules/unauthenticated-users-cluster-role-binding.adoc b/modules/unauthenticated-users-cluster-role-binding.adoc index e93a8271327f..38e936eed79b 100644 --- a/modules/unauthenticated-users-cluster-role-binding.adoc +++ b/modules/unauthenticated-users-cluster-role-binding.adoc @@ -9,7 +9,8 @@ [id="unauthenticated-users-cluster-role-bindings_{context}"] = Adding unauthenticated groups to cluster roles -As a cluster administrator, you can add unauthenticated users to the following cluster roles in {product-title} by creating a cluster role binding. Unauthenticated users do not have access to non-public cluster roles. This should only be done in specific use cases when necessary. +[role="_abstract"] +As a cluster administrator, you can add unauthenticated users to specific cluster roles by creating a cluster role binding when required for your use case. You can add unauthenticated users to the following cluster roles: diff --git a/post_installation_configuration/changing-cloud-credentials-configuration.adoc b/post_installation_configuration/changing-cloud-credentials-configuration.adoc index c947824d8b61..a7b0aaaa13fe 100644 --- a/post_installation_configuration/changing-cloud-credentials-configuration.adoc +++ b/post_installation_configuration/changing-cloud-credentials-configuration.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] For supported configurations, you can change how {product-title} authenticates with your cloud provider. To determine which cloud credentials strategy your cluster uses, see xref:../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#cco-determine-mode_about-cloud-credential-operator[Determining the Cloud Credential Operator mode]. diff --git a/post_installation_configuration/cluster-tasks.adoc b/post_installation_configuration/cluster-tasks.adoc index ccafd441a96b..d61c8ba04a18 100644 --- a/post_installation_configuration/cluster-tasks.adoc +++ b/post_installation_configuration/cluster-tasks.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] After installing {product-title}, you can further expand and customize your cluster to your requirements. [id="available_cluster_customizations"] diff --git a/post_installation_configuration/configuring-alert-notifications.adoc b/post_installation_configuration/configuring-alert-notifications.adoc index 9ad0bf6beaa1..91a927ee3aee 100644 --- a/post_installation_configuration/configuring-alert-notifications.adoc +++ b/post_installation_configuration/configuring-alert-notifications.adoc @@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -In {product-title}, an alert is fired when the conditions defined in an alerting rule are true. An alert provides a notification that a set of circumstances are apparent within a cluster. Firing alerts can be viewed in the Alerting UI in the {product-title} web console by default. After an installation, you can configure {product-title} to send alert notifications to external systems. +[role="_abstract"] +In {product-title}, an alert is fired when the conditions defined in an alerting rule are true. After an installation, you can configure {product-title} to send alert notifications to external systems. include::modules/monitoring-sending-notifications-to-external-systems.adoc[leveloffset=+1] diff --git a/post_installation_configuration/configuring-private-cluster.adoc b/post_installation_configuration/configuring-private-cluster.adoc index 3497f3dad372..8afd97850641 100644 --- a/post_installation_configuration/configuring-private-cluster.adoc +++ b/post_installation_configuration/configuring-private-cluster.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] After you install an {product-title} version {product-version} cluster, you can set some of its core components to be private. include::modules/private-clusters-about.adoc[leveloffset=+1] diff --git a/post_installation_configuration/converting-to-disconnected.adoc b/post_installation_configuration/converting-to-disconnected.adoc index e3c75b0f3ce4..651ee3236869 100644 --- a/post_installation_configuration/converting-to-disconnected.adoc +++ b/post_installation_configuration/converting-to-disconnected.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] There might be some scenarios where you need to convert your {product-title} cluster from a connected cluster to a disconnected cluster. A disconnected cluster, also known as a restricted cluster, does not have an active connection to the internet. As such, you must mirror the contents of your registries and installation media. You can create this mirror registry on a host that can access both the internet and your closed network, or copy images to a device that you can move across network boundaries. diff --git a/post_installation_configuration/index.adoc b/post_installation_configuration/index.adoc index b09aeb157789..e58a26665f34 100644 --- a/post_installation_configuration/index.adoc +++ b/post_installation_configuration/index.adoc @@ -6,7 +6,10 @@ include::_attributes/common-attributes.adoc[] toc::[] -After installing {product-title}, a cluster administrator can configure and customize the following components: +[role="_abstract"] +After installing {product-title}, a cluster administrator can configure and customize machine, bare metal, cluster, node, network, storage, user, and alert and notification components. + +The following components are available for postinstallation configuration: * Machine * Bare metal diff --git a/post_installation_configuration/node-tasks.adoc b/post_installation_configuration/node-tasks.adoc index f6a3b87d46c9..9e8687ec8423 100644 --- a/post_installation_configuration/node-tasks.adoc +++ b/post_installation_configuration/node-tasks.adoc @@ -6,8 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -After installing {product-title}, you can further expand and customize your -cluster to your requirements through certain node tasks. +[role="_abstract"] +After installing {product-title}, you can further expand and customize your cluster to your requirements through certain node tasks. [id="post-install-config-adding-fcos-compute"] == Adding {op-system} compute machines to an {product-title} cluster diff --git a/post_installation_configuration/post-install-image-config.adoc b/post_installation_configuration/post-install-image-config.adoc index a9a0706d6950..5439f977181c 100644 --- a/post_installation_configuration/post-install-image-config.adoc +++ b/post_installation_configuration/post-install-image-config.adoc @@ -7,10 +7,14 @@ include::_attributes/attributes-openshift-dedicated.adoc[] toc::[] -You can update the global pull secret for your cluster by either replacing the current pull secret or appending a new pull secret. The procedure is required when users use a separate registry to store images than the registry used during installation. For more information, see xref:../openshift_images/managing_images/using-image-pull-secrets.adoc#using-image-pull-secrets[Using image pull secrets]. +[role="_abstract"] +You can update the global pull secret for your cluster by either replacing the current pull secret or appending a new pull secret. -For information about images and configuring image streams or image registries, see the following documentation: +The procedure is required when users use a separate registry to store images than the registry used during installation. +[role="_additional-resources"] +.Additional resources +* xref:../openshift_images/managing_images/using-image-pull-secrets.adoc#using-image-pull-secrets[Using image pull secrets] * xref:../openshift_images/index.adoc#overview-of-images[Overview of images] * xref:../registry/configuring-registry-operator.adoc#configuring-registry-operator[Image Registry Operator in {product-title}] * xref:../openshift_images/image-configuration.adoc#image-configuration[Configuring image registry settings] diff --git a/post_installation_configuration/post-install-network-configuration.adoc b/post_installation_configuration/post-install-network-configuration.adoc index ad25f2dc1096..ebb82e020c99 100644 --- a/post_installation_configuration/post-install-network-configuration.adoc +++ b/post_installation_configuration/post-install-network-configuration.adoc @@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[] toc::[] +[role="_abstract"] After installing {product-title}, you can further expand and customize your network to your requirements. [id="post-install-network-configuration-cno"] diff --git a/post_installation_configuration/post-install-storage-configuration.adoc b/post_installation_configuration/post-install-storage-configuration.adoc index cd507a9e813d..c8a0c739b57d 100644 --- a/post_installation_configuration/post-install-storage-configuration.adoc +++ b/post_installation_configuration/post-install-storage-configuration.adoc @@ -20,6 +20,7 @@ endif::[] toc::[] +[role="_abstract"] After installing {product-title}, you can further expand and customize your cluster to your requirements, including storage configuration. By default, containers operate by using the ephemeral storage or transient local storage. The ephemeral storage has a lifetime limitation. To store the data for a long time, you must configure persistent storage. You can configure storage by using one of the following methods: diff --git a/post_installation_configuration/preparing-for-users.adoc b/post_installation_configuration/preparing-for-users.adoc index 0462e70adf90..9e0899ec07ed 100644 --- a/post_installation_configuration/preparing-for-users.adoc +++ b/post_installation_configuration/preparing-for-users.adoc @@ -6,8 +6,8 @@ include::_attributes/common-attributes.adoc[] toc::[] -After installing {product-title}, you can further expand and customize your -cluster to your requirements, including taking steps to prepare for users. +[role="_abstract"] +After installing {product-title}, you can further expand and customize your cluster to your requirements, including taking steps to prepare for users. [id="post-install-understanding-identity-provider"] == Understanding identity provider configuration