From 4a0bd7b8b1fd3e7a6b9de636ed35c508d046fc48 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E2=80=9CShauna=20Diaz=E2=80=9D?= Date: Tue, 30 Sep 2025 07:55:42 -0400 Subject: [PATCH] OSDOCS-16338: fixes cluster mentions MicroShift --- _topic_maps/_topic_map_ms.yml | 14 +++++------ .../microshift-cli-using-oc.adoc | 2 +- .../microshift-usage-oc-kubectl.adoc | 2 +- .../microshift-node-access-kubeconfig.adoc | 2 +- .../microshift-using-config-yaml.adoc | 2 +- .../microshift-tls-config.adoc | 2 +- ...icroshift-deploy-with-mirror-registry.adoc | 2 +- .../microshift-install-optional-rpms.adoc | 2 +- ...shift-embed-in-rpm-ostree-offline-use.adoc | 2 +- microshift_networking/microshift-cni.adoc | 2 +- .../microshift-configuring-routes.adoc | 2 +- .../microshift-networking-settings.adoc | 6 ++--- .../microshift-cni-multus.adoc | 2 +- .../microshift-network-policy-index.adoc | 2 +- .../microshift-viewing-network-policy.adoc | 2 +- ...icroshift-deleting-resource-manifests.adoc | 2 +- .../microshift-embed-apps-offline-use.adoc | 2 +- ...microshift-embedded-apps-on-rhel-edge.adoc | 2 +- .../microshift-embedding-apps-tutorial.adoc | 2 +- .../microshift-gitops.adoc | 6 ++--- ...hift-operators-oc-mirror-disconnected.adoc | 2 +- .../microshift-operators-oc-mirror.adoc | 4 ++-- .../microshift-operators-olm.adoc | 14 +++++------ .../microshift-operators.adoc | 8 +++---- microshift_storage/index.adoc | 4 ++-- .../microshift-storage-migration.adoc | 2 +- ...tanding-persistent-storage-microshift.adoc | 2 +- .../volume-snapshots-microshift.adoc | 6 ++--- .../microshift-getting-cluster-id.adoc | 18 -------------- .../microshift-getting-node-id.adoc | 18 ++++++++++++++ ...=> microshift-remote-node-monitoring.adoc} | 13 +++++----- .../microshift-troubleshoot-cluster.adoc | 11 --------- .../microshift-troubleshoot-node.adoc | 11 +++++++++ .../microshift-update-options.adoc | 2 +- ...oshift-about-remote-health-monitoring.adoc | 12 +++++----- modules/microshift-about-sos-reports.adoc | 5 ++-- ...microshift-applying-manifests-example.adoc | 2 +- modules/microshift-arch-design.adoc | 16 ++++++------- .../microshift-audit-logs-config-intro.adoc | 4 ++-- modules/microshift-ca-adding-bundle.adoc | 2 +- ...adoc => microshift-check-node-status.adoc} | 11 +++++---- modules/microshift-cli-oc-about.adoc | 2 +- ...ift-cni-multus-nad-additional-network.adoc | 6 ++--- ...n-understanding-generic-device-plugin.adoc | 2 +- .../microshift-config-parameters-table.adoc | 10 ++++---- modules/microshift-config-yaml-custom.adoc | 2 +- modules/microshift-config-yaml.adoc | 2 +- ...missions-security-context-constraints.adoc | 2 +- ...oshift-creating-backups-auto-recovery.adoc | 4 ++-- .../microshift-custom-ca-cert-cleaning.adoc | 2 +- modules/microshift-custom-ca-con.adoc | 2 +- modules/microshift-custom-ca-proc.adoc | 2 +- .../microshift-custom-ca-reserved-names.adoc | 2 +- .../microshift-deploying-a-load-balancer.adoc | 6 ++--- .../microshift-disabling-lvms-csi-driver.adoc | 9 ++----- ...abling-uninstalling-lvms-csi-snapshot.adoc | 2 +- modules/microshift-disconnected-host-con.adoc | 6 ++--- ...icroshift-disconnected-host-procedure.adoc | 12 +++++----- ...hift-exposed-audit-ports-loadbalancer.adoc | 3 +-- modules/microshift-fips-rpm-system.adoc | 2 +- modules/microshift-firewall-known-issue.adoc | 2 +- modules/microshift-firewall-req-settings.adoc | 2 +- ...icroshift-firewall-update-for-service.adoc | 2 +- modules/microshift-gathering-sos-report.adoc | 2 +- ...=> microshift-get-node-id-kubesystem.adoc} | 12 +++++----- ...-get-nonrunning-cluster-id-kubesystem.adoc | 24 ------------------- ...ift-get-nonrunning-node-id-kubesystem.adoc | 24 +++++++++++++++++++ modules/microshift-http-proxy.adoc | 2 +- .../microshift-info-collected-telemetry.adoc | 12 +++++----- ...croshift-install-multus-running-node.adoc} | 8 +++---- modules/microshift-install-rhde-steps.adoc | 4 ++-- modules/microshift-install-rhel-types.adoc | 4 ++-- modules/microshift-install-rpm-before.adoc | 4 ++-- modules/microshift-install-rpms-olm.adoc | 4 ++-- ...ubeconfig-generating-additional-files.adoc | 2 +- .../microshift-kubeconfig-local-access.adoc | 2 +- modules/microshift-kubeconfig-overview.adoc | 2 +- modules/microshift-low-latency-concept.adoc | 4 ++-- .../microshift-low-latency-config-yaml.adoc | 6 ++--- ...ow-latency-install-kernelrt-rhel-edge.adoc | 2 +- ...hift-low-latency-install-kernelrt-rpm.adoc | 2 +- ...croshift-low-latency-prepare-workload.adoc | 4 ++-- .../microshift-low-latency-tuned-conc.adoc | 2 +- .../microshift-low-latency-tuned-profile.adoc | 4 ++-- modules/microshift-lvm-thin-volumes.adoc | 4 ++-- modules/microshift-lvms-deployment.adoc | 2 +- modules/microshift-manifests-overview.adoc | 8 +++---- modules/microshift-multus-intro.adoc | 4 ++-- modules/microshift-nw-advertise-address.adoc | 4 ++-- ...microshift-nw-create-http-based-route.adoc | 5 ++-- ...croshift-nw-enforcing-hsts-per-domain.adoc | 6 ++--- modules/microshift-nw-ipv6-concept.adoc | 8 +++---- .../microshift-nw-ipv6-dual-stack-config.adoc | 12 +++++----- ...t-nw-ipv6-dual-stack-migrating-config.adoc | 18 +++++++------- ...icroshift-nw-ipv6-single-stack-config.adoc | 6 ++--- modules/microshift-nw-multus-add-pod.adoc | 4 ++-- .../microshift-nw-network-policy-intro.adoc | 9 +++---- modules/microshift-nw-topology.adoc | 2 +- modules/microshift-oc-apis-errors.adoc | 24 +++++++++++-------- modules/microshift-oc-mirror-about-con.adoc | 2 +- .../microshift-oc-mirror-connectivity.adoc | 6 ++--- ...ft-oc-mirror-creating-imageset-config.adoc | 2 +- ...shift-oc-mirror-install-catalog-node.adoc} | 4 ++-- modules/microshift-oc-mirror-to-mirror.adoc | 2 +- ...oshift-olm-deploy-op-disconnected-con.adoc | 10 ++++---- modules/microshift-olm-deploy-ops-con.adoc | 6 ++--- .../microshift-olm-deploy-ops-global-ns.adoc | 4 ++-- .../microshift-olm-deploy-ops-spec-ns.adoc | 4 ++-- .../microshift-ops-config-embed-ostree.adoc | 2 +- modules/microshift-opt-out-telemetry.adoc | 8 +++---- modules/microshift-otel-config-examples.adoc | 4 ++-- modules/microshift-ovs-snapshot.adoc | 6 ++--- ...ft-preparing-for-image-building-bootc.adoc | 2 +- ...croshift-preparing-for-image-building.adoc | 2 +- ...microshift-preparing-to-make-app-rpms.adoc | 2 +- ...roc-configuring-generic-device-plugin.adoc | 6 ++--- ...ing-applications-with-generic-devices.adoc | 4 ++-- ...evice-plugin-configuration-parameters.adoc | 2 +- ...generic-device-plugin-troubleshooting.adoc | 2 +- .../microshift-restart-ovnkube-master.adoc | 6 ++--- ...shift-restoring-backups-auto-recovery.adoc | 2 +- .../microshift-restoring-data-backups.adoc | 2 +- ...shift-rhoai-get-model-ready-inference.adoc | 2 +- ...oshift-rhoai-get-model-server-metrics.adoc | 2 +- ...roshift-rhoai-model-serving-rt-verify.adoc | 2 +- modules/microshift-rhoai-query-model.adoc | 2 +- ...icroshift-rhoai-serving-ai-models-con.adoc | 4 ++-- .../microshift-rhoai-servingruntimes-ex.adoc | 2 +- ...croshift-rhoai-verify-model-connected.adoc | 4 ++-- modules/microshift-rhoai-workflow.adoc | 2 +- ...t-security-context-constraints-opting.adoc | 4 ++-- ...croshift-security-context-constraints.adoc | 2 +- ...icroshift-storage-about-vol-snapshots.adoc | 2 +- ...shift-storage-backup-volume-snapshots.adoc | 2 +- modules/microshift-storage-classes.adoc | 2 +- ...roshift-storage-creating-vol-snapshot.adoc | 6 ++--- ...microshift-storage-vol-snapshot-class.adoc | 2 +- modules/microshift-tls-config-proc.adoc | 4 ++-- .../microshift-uninstall-microshift-rpms.adoc | 2 +- ...croshift-uninstalling-lvms-csi-driver.adoc | 2 +- ...oshift-uninstalling-lvms-csi-snapshot.adoc | 2 +- .../microshift-updates-rpms-ostree-con.adoc | 2 +- modules/microshift-viewing-audit-logs.adoc | 2 +- 143 files changed, 348 insertions(+), 353 deletions(-) delete mode 100644 microshift_support/microshift-getting-cluster-id.adoc create mode 100644 microshift_support/microshift-getting-node-id.adoc rename microshift_support/{microshift-remote-cluster-monitoring.adoc => microshift-remote-node-monitoring.adoc} (51%) delete mode 100644 microshift_troubleshooting/microshift-troubleshoot-cluster.adoc create mode 100644 microshift_troubleshooting/microshift-troubleshoot-node.adoc rename modules/{microshift-check-cluster-status.adoc => microshift-check-node-status.adoc} (73%) rename modules/{microshift-get-cluster-id-kubesystem.adoc => microshift-get-node-id-kubesystem.adoc} (57%) delete mode 100644 modules/microshift-get-nonrunning-cluster-id-kubesystem.adoc create mode 100644 modules/microshift-get-nonrunning-node-id-kubesystem.adoc rename modules/{microshift-install-multus-running-cluster.adoc => microshift-install-multus-running-node.adoc} (82%) rename modules/{microshift-oc-mirror-install-catalog-cluster.adoc => microshift-oc-mirror-install-catalog-node.adoc} (91%) diff --git a/_topic_maps/_topic_map_ms.yml b/_topic_maps/_topic_map_ms.yml index 14450614d956..55512aa337da 100644 --- a/_topic_maps/_topic_map_ms.yml +++ b/_topic_maps/_topic_map_ms.yml @@ -250,7 +250,7 @@ Topics: File: microshift-operators-olm - Name: Creating custom catalogs with oc-mirror File: microshift-operators-oc-mirror - - Name: Adding OLM-based Operators to a disconnected cluster + - Name: Adding OLM-based Operators to a disconnected node File: microshift-operators-oc-mirror-disconnected --- Name: Backup and restore @@ -270,12 +270,12 @@ Topics: File: microshift-etcd - Name: The sos report tool File: microshift-sos-report -- Name: Getting your cluster ID - File: microshift-getting-cluster-id +- Name: Getting your node ID + File: microshift-getting-node-id - Name: Getting support File: microshift-getting-support -- Name: Remote health monitoring with a connected cluster - File: microshift-remote-cluster-monitoring +- Name: Remote health monitoring with a connected node + File: microshift-remote-node-monitoring --- Name: Troubleshooting Dir: microshift_troubleshooting @@ -283,8 +283,8 @@ Distros: microshift Topics: - Name: Check your version File: microshift-version -- Name: Troubleshoot the cluster - File: microshift-troubleshoot-cluster +- Name: Troubleshoot the node + File: microshift-troubleshoot-node - Name: Troubleshoot installation issues File: microshift-installing-troubleshooting - Name: Troubleshoot backup and restore diff --git a/microshift_cli_ref/microshift-cli-using-oc.adoc b/microshift_cli_ref/microshift-cli-using-oc.adoc index 5fe554974638..4358acb59d8f 100644 --- a/microshift_cli_ref/microshift-cli-using-oc.adoc +++ b/microshift_cli_ref/microshift-cli-using-oc.adoc @@ -11,7 +11,7 @@ The optional {oc-first} tool provides a subset of `oc` commands for {microshift- include::modules/microshift-cli-oc-about.adoc[leveloffset=+1] [id="cli-using-cli_{context}"] -== Using oc with a {microshift-short} cluster +== Using oc with a {microshift-short} node Review the following sections to learn how to complete common tasks in {microshift-short} using the `oc` CLI. diff --git a/microshift_cli_ref/microshift-usage-oc-kubectl.adoc b/microshift_cli_ref/microshift-usage-oc-kubectl.adoc index a4b8e241b541..019f3bd12524 100644 --- a/microshift_cli_ref/microshift-usage-oc-kubectl.adoc +++ b/microshift_cli_ref/microshift-usage-oc-kubectl.adoc @@ -11,7 +11,7 @@ The Kubernetes command-line interface (CLI), `kubectl`, can be used to run comma [id="microshift-kubectl-binary_{context}"] == The kubectl CLI tool -You can use the `kubectl` CLI tool to interact with Kubernetes primitives on your {microshift-short} cluster. You can also use existing `kubectl` workflows and scripts for users coming from another Kubernetes environment, or for those who prefer to use the `kubectl` CLI. +You can use the `kubectl` CLI tool to interact with Kubernetes primitives on your {microshift-short} node. You can also use existing `kubectl` workflows and scripts for users coming from another Kubernetes environment, or for those who prefer to use the `kubectl` CLI. * The `kubectl` CLI tool is included in the archive when you download `oc`. diff --git a/microshift_configuring/microshift-node-access-kubeconfig.adoc b/microshift_configuring/microshift-node-access-kubeconfig.adoc index 4417d08d6b88..56df090645b7 100644 --- a/microshift_configuring/microshift-node-access-kubeconfig.adoc +++ b/microshift_configuring/microshift-node-access-kubeconfig.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -Learn about how `kubeconfig` files are used with {microshift-short} deployments. CLI tools use `kubeconfig` files to communicate with the API server of a cluster. These files provide cluster details, IP addresses, and other information needed for authentication. +Learn about how `kubeconfig` files are used with {microshift-short} deployments. CLI tools use `kubeconfig` files to communicate with the API server of a node. These files provide node details, IP addresses, and other information needed for authentication. include::modules/microshift-kubeconfig-overview.adoc[leveloffset=+1] diff --git a/microshift_configuring/microshift-using-config-yaml.adoc b/microshift_configuring/microshift-using-config-yaml.adoc index 6801ec1979ee..f4edfb6503d4 100644 --- a/microshift_configuring/microshift-using-config-yaml.adoc +++ b/microshift_configuring/microshift-using-config-yaml.adoc @@ -20,7 +20,7 @@ include::modules/microshift-nw-advertise-address.adoc[leveloffset=+2] include::modules/microshift-config-nodeport-limits.adoc[leveloffset=+2] -[id="additional-resources_microshift-using-config-yaml_{context}"] +[id="additional-resources_microshift-using-config-yaml"] [role="_additional-resources"] == Additional resources diff --git a/microshift_configuring/microshift_auth_security/microshift-tls-config.adoc b/microshift_configuring/microshift_auth_security/microshift-tls-config.adoc index 2807653667b4..319ac1fbe78c 100644 --- a/microshift_configuring/microshift_auth_security/microshift-tls-config.adoc +++ b/microshift_configuring/microshift_auth_security/microshift-tls-config.adoc @@ -20,5 +20,5 @@ include::modules/microshift-tls-default-cipher-suites.adoc[leveloffset=+2] * xref:../../microshift_configuring/microshift-config-snippets.adoc#microshift-config-snippets[Using configuration snippets] * xref:../../microshift_running_apps/microshift-authentication.adoc#authentication-microshift[Pod security authentication and authorization with SCC] -* xref:../../microshift_configuring/microshift-node-access-kubeconfig#microshift-node-access-kubeconfig[Cluster access with kubeconfig] +* xref:../../microshift_configuring/microshift-node-access-kubeconfig#microshift-node-access-kubeconfig[Node access with kubeconfig] * xref:../microshift_auth_security/microshift-custom-ca.adoc#microshift-custom-ca[Configuring custom certificate authorities] diff --git a/microshift_install_get_ready/microshift-deploy-with-mirror-registry.adoc b/microshift_install_get_ready/microshift-deploy-with-mirror-registry.adoc index 51a937fae5de..34716cd270f1 100644 --- a/microshift_install_get_ready/microshift-deploy-with-mirror-registry.adoc +++ b/microshift_install_get_ready/microshift-deploy-with-mirror-registry.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -You can use a custom container registry when you deploy {microshift-short} in a disconnected network. Running your cluster in a restricted network without direct internet connectivity is possible by installing the cluster from a mirrored set of container images in a private registry. +You can use a custom container registry when you deploy {microshift-short} in a disconnected network. Running your node in a restricted network without direct internet connectivity is possible by installing the node from a mirrored set of container images in a private registry. include::modules/microshift-mirror-container-images.adoc[leveloffset=+1] diff --git a/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc b/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc index 57399f46c920..cd0f31c929a3 100644 --- a/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc +++ b/microshift_install_rpm_opt/microshift-install-optional-rpms.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -You can install optional RPM packages with {microshift-short} to provide additional cluster and application services. +You can install optional RPM packages with {microshift-short} to provide additional node and application services. [id="microshift-install-rpm-add-ons"] == Installing optional packages diff --git a/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc b/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc index c214e79eb8d3..dcf5bec83ea1 100644 --- a/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc +++ b/microshift_install_rpm_ostree/microshift-embed-in-rpm-ostree-offline-use.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -Embedding {microshift-short} containers in an `rpm-ostree` commit means that you can run a cluster in air-gapped, disconnected, or offline environments. You can embed {product-title} containers in a {op-system-ostree-first} image so that container engines do not need to pull images over a network from a container registry. Workloads can start immediately without network connectivity. +Embedding {microshift-short} containers in an `rpm-ostree` commit means that you can run a node in air-gapped, disconnected, or offline environments. You can embed {product-title} containers in a {op-system-ostree-first} image so that container engines do not need to pull images over a network from a container registry. Workloads can start immediately without network connectivity. include::modules/microshift-embed-microshift-image-offline-deploy.adoc[leveloffset=+1] diff --git a/microshift_networking/microshift-cni.adoc b/microshift_networking/microshift-cni.adoc index 84201632433c..a5f4fbf718ea 100644 --- a/microshift_networking/microshift-cni.adoc +++ b/microshift_networking/microshift-cni.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -The OVN-Kubernetes Container Network Interface (CNI) plugin is the default networking solution for the {microshift-short} node. OVN-Kubernetes is a virtualized network for pods and services that is based on Open Virtual Network (OVN). +The OVN-Kubernetes Container Network Interface (CNI) plugin is the default networking solution for a {microshift-short} node. OVN-Kubernetes is a virtualized network for pods and services that is based on Open Virtual Network (OVN). * Default network configuration and connections are applied automatically in {microshift-short} with the `microshift-networking` RPM during installation. * A node that uses the OVN-Kubernetes network plugin also runs Open vSwitch (OVS) on the node. diff --git a/microshift_networking/microshift-configuring-routes.adoc b/microshift_networking/microshift-configuring-routes.adoc index 4a4759c231e1..c9a94b024acc 100644 --- a/microshift_networking/microshift-configuring-routes.adoc +++ b/microshift_networking/microshift-configuring-routes.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -You can configure routes for services to have {microshift-short} cluster access. +You can configure routes for services to have {microshift-short} node access. //OCP module, edit with care; Creating an insecure/http route include::modules/microshift-nw-create-http-based-route.adoc[leveloffset=+1] diff --git a/microshift_networking/microshift-networking-settings.adoc b/microshift_networking/microshift-networking-settings.adoc index 5095b60ada94..ff3bf6554b53 100644 --- a/microshift_networking/microshift-networking-settings.adoc +++ b/microshift_networking/microshift-networking-settings.adoc @@ -8,13 +8,13 @@ toc::[] Learn how to apply networking customization and default settings to {microshift-short} deployments. Each node is contained to a single machine and single {microshift-short}, so each deployment requires individual configuration, pods, and settings. -Cluster Administrators have several options for exposing applications that run inside a cluster to external traffic and securing network connections: +{microshift-short} administrators have several options for exposing applications that run inside a node to external traffic and securing network connections: * A service such as NodePort * API resources, such as `Ingress` and `Route` -By default, Kubernetes allocates each pod an internal IP address for applications running within the pod. Pods and their containers can have traffic between them, but clients outside the cluster do not have direct network access to pods except when exposed with a service such as NodePort. +By default, Kubernetes allocates each pod an internal IP address for applications running within the pod. Pods and their containers can have traffic between them, but clients outside the node do not have direct network access to pods except when exposed with a service such as NodePort. include::modules/microshift-configuring-ovn.adoc[leveloffset=+1] @@ -31,7 +31,7 @@ include::modules/microshift-ovs-snapshot.adoc[leveloffset=+1] [id="microshift-about-load-balancer-service_{context}"] == The {microshift-short} LoadBalancer service for workloads -{microshift-short} has a built-in implementation of network load balancers that you can use for your workloads and applications within the cluster. You can create a `LoadBalancer` service by configuring a pod to interpret ingress rules and serve as an ingress controller. The following procedure gives an example of a deployment-based `LoadBalancer` service. +{microshift-short} has a built-in implementation of network load balancers that you can use for your workloads and applications within the node. You can create a `LoadBalancer` service by configuring a pod to interpret ingress rules and serve as an ingress controller. The following procedure gives an example of a deployment-based `LoadBalancer` service. include::modules/microshift-deploying-a-load-balancer.adoc[leveloffset=+1] diff --git a/microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc b/microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc index 796ab3b44b23..d04d5cc16e82 100644 --- a/microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc +++ b/microshift_networking/microshift_multiple_networks/microshift-cni-multus.adoc @@ -10,7 +10,7 @@ In addition to the default OVN-Kubernetes Container Network Interface (CNI) plug include::modules/microshift-multus-intro.adoc[leveloffset=+1] -include::modules/microshift-install-multus-running-cluster.adoc[leveloffset=+1] +include::modules/microshift-install-multus-running-node.adoc[leveloffset=+1] //OCP module, edit with conditionals and care include::modules/nw-multus-bridge-object.adoc[leveloffset=+1] diff --git a/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc b/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc index f53c003064d9..ee68cd7311f6 100644 --- a/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc +++ b/microshift_networking/microshift_network_policy/microshift-network-policy-index.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -Learn how network policies work for {microshift-short} to restrict or allow network traffic to pods in your cluster. +Learn how network policies work for {microshift-short} to restrict or allow network traffic to pods in your node. include::modules/microshift-nw-network-policy-intro.adoc[leveloffset=+1] diff --git a/microshift_networking/microshift_network_policy/microshift-viewing-network-policy.adoc b/microshift_networking/microshift_network_policy/microshift-viewing-network-policy.adoc index f0ba875be413..ed5143552942 100644 --- a/microshift_networking/microshift_network_policy/microshift-viewing-network-policy.adoc +++ b/microshift_networking/microshift_network_policy/microshift-viewing-network-policy.adoc @@ -9,4 +9,4 @@ toc::[] Use the following procedure to view a network policy for a namespace. -include::modules/nw-networkpolicy-view-cli.adoc[leveloffset=+1] \ No newline at end of file +include::modules/nw-networkpolicy-view-cli.adoc[leveloffset=+1] diff --git a/microshift_running_apps/microshift-deleting-resource-manifests.adoc b/microshift_running_apps/microshift-deleting-resource-manifests.adoc index b6d459ab0452..b9f26540f47f 100644 --- a/microshift_running_apps/microshift-deleting-resource-manifests.adoc +++ b/microshift_running_apps/microshift-deleting-resource-manifests.adoc @@ -8,7 +8,7 @@ toc::[] {microshift-short} supports the deletion of manifest resources in the following situations: -* Manifest removal: Manifests can be removed when you need to completely remove a resource from the cluster. +* Manifest removal: Manifests can be removed when you need to completely remove a resource from the node. * Manifest upgrade: During an application upgrade, some resources might need to be removed while others are retained to preserve data. When creating new manifests, you can use manifest resource deletion to remove or update old objects, ensuring there are no conflicts or issues. diff --git a/microshift_running_apps/microshift-embed-apps-offline-use.adoc b/microshift_running_apps/microshift-embed-apps-offline-use.adoc index fb799ded1ee3..929e0286a9cc 100644 --- a/microshift_running_apps/microshift-embed-apps-offline-use.adoc +++ b/microshift_running_apps/microshift-embed-apps-offline-use.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -You can embed microservices-based workloads and applications in a {op-system-ostree-first} image. Embedding means you can run a {product-title} cluster in air-gapped, disconnected, or offline environments. +You can embed microservices-based workloads and applications in a {op-system-ostree-first} image. Embedding means you can run a {microshift-short} node in air-gapped, disconnected, or offline environments. include::modules/microshift-embed-images-offline-use.adoc[leveloffset=+1] diff --git a/microshift_running_apps/microshift-embedded-apps-on-rhel-edge.adoc b/microshift_running_apps/microshift-embedded-apps-on-rhel-edge.adoc index 7696dd7edc39..5f89a2322717 100644 --- a/microshift_running_apps/microshift-embedded-apps-on-rhel-edge.adoc +++ b/microshift_running_apps/microshift-embedded-apps-on-rhel-edge.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -You can embed microservices-based workloads and applications in a {op-system-ostree-first} image to run in a {microshift-short} cluster. Embedded applications can be installed directly on edge devices to run in disconnected or offline environments. +You can embed microservices-based workloads and applications in a {op-system-ostree-first} image to run in a {microshift-short} node. Embedded applications can be installed directly on edge devices to run in disconnected or offline environments. [id="microshift-add-app-RPMs-to-rpm-ostree-image_{context}"] == Adding application RPMs to an rpm-ostree image diff --git a/microshift_running_apps/microshift-embedding-apps-tutorial.adoc b/microshift_running_apps/microshift-embedding-apps-tutorial.adoc index c25990d6994c..de139319a417 100644 --- a/microshift_running_apps/microshift-embedding-apps-tutorial.adoc +++ b/microshift_running_apps/microshift-embedding-apps-tutorial.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -The following tutorial gives a detailed example of how to embed applications in a {op-system-ostree} image for use in a {microshift-short} cluster in various environments. +The following tutorial gives a detailed example of how to embed applications in a {op-system-ostree} image for use in a {microshift-short} node in various environments. include::modules/microshift-embed-app-rpms-tutorial.adoc[leveloffset=+1] diff --git a/microshift_running_apps/microshift-gitops.adoc b/microshift_running_apps/microshift-gitops.adoc index a6f3b72972c7..1e74356fa48e 100644 --- a/microshift_running_apps/microshift-gitops.adoc +++ b/microshift_running_apps/microshift-gitops.adoc @@ -6,14 +6,14 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -GitOps with Argo CD for {microshift-short} is a lightweight, optional add-on controller derived from the Red Hat OpenShift GitOps Operator. GitOps for {microshift-short} uses the command-line interface (CLI) of Argo CD to interact with the GitOps controller that acts as the declarative GitOps engine. You can consistently configure and deploy Kubernetes-based infrastructure and applications across clusters and development lifecycles. +GitOps with Argo CD for {microshift-short} is a lightweight, optional add-on controller derived from the Red Hat OpenShift GitOps Operator. GitOps for {microshift-short} uses the command-line interface (CLI) of Argo CD to interact with the GitOps controller that acts as the declarative GitOps engine. You can consistently configure and deploy Kubernetes-based infrastructure and applications across node and development lifecycles. [id="microshift-gitops-can-do_{context}"] == What you can do with the GitOps agent By using the GitOps with Argo CD agent with {microshift-short}, you can utilize the following principles: * Implement application lifecycle management. -** Create and manage your clusters and application configuration files using the core principles of developing and maintaining software in a Git repository. +** Create and manage your node and application configuration files using the core principles of developing and maintaining software in a Git repository. ** You can update the single repository and GitOps automates the deployment of new applications or updates to existing ones. ** For example, if you have 1,000 edge devices, each using {microshift-short} and a local GitOps agent, you can easily add or update an application on all 1,000 devices with just one change in your central Git repository. * The Git repository contains a declarative description of the infrastructure you need in your specified environment and contains an automated process to make your environment match the described state. @@ -31,7 +31,7 @@ GitOps with Argo CD for {microshift-short} has the following differences from th * The `gitops-operator` component is not used with {microshift-short}. * To maintain the small resource use of {microshift-short}, the Argo CD web console is not available. You can use the Argo CD CLI. -* Because {microshift-short} is single-node, there is no multi-cluster support. Each instance of {microshift-short} is paired with a local GitOps agent. +* Because {microshift-short} is single-node, there is no multi-node support. Each instance of {microshift-short} is paired with a local GitOps agent. * The `oc adm must-gather` command is not available in {microshift-short}. [id="microshift-gitops-troubleshooting_{context}"] diff --git a/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror-disconnected.adoc b/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror-disconnected.adoc index b63f55017d6e..be5c7f8fa38d 100644 --- a/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror-disconnected.adoc +++ b/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror-disconnected.adoc @@ -1,6 +1,6 @@ :_mod-docs-content-type: ASSEMBLY [id="microshift-operators-oc-mirror-disconnected"] -= Adding OLM-based Operators to a disconnected cluster += Adding OLM-based Operators to a disconnected node include::_attributes/attributes-microshift.adoc[] :context: microshift-operators-oc-mirror-disconnected diff --git a/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror.adoc b/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror.adoc index a18c7b7c4983..8afad988bc89 100644 --- a/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror.adoc +++ b/microshift_running_apps/microshift_operators/microshift-operators-oc-mirror.adoc @@ -28,8 +28,8 @@ include::modules/microshift-oc-mirror-to-mirror.adoc[leveloffset=+1] //Convert the imageset file and add configuration to CRI-O include::modules/microshift-oc-mirror-transform-imageset-to-crio.adoc[leveloffset=+1] -//Apply changes to cluster so it can use Operators -include::modules/microshift-oc-mirror-install-catalog-cluster.adoc[leveloffset=+1] +//Apply changes to node so it can use Operators +include::modules/microshift-oc-mirror-install-catalog-node.adoc[leveloffset=+1] [id="Additional-resources_microshift-operators-oc-mirror_{context}"] [role="_additional-resources"] diff --git a/microshift_running_apps/microshift_operators/microshift-operators-olm.adoc b/microshift_running_apps/microshift_operators/microshift-operators-olm.adoc index facf5035c956..468b8c885473 100644 --- a/microshift_running_apps/microshift_operators/microshift-operators-olm.adoc +++ b/microshift_running_apps/microshift_operators/microshift-operators-olm.adoc @@ -15,10 +15,10 @@ Operator Lifecycle Manager (OLM) is used in {microshift-short} for installing an * Cluster Operators as applied in {ocp} are not used in {microshift-short}. * You must create your own catalogs for the add-on Operators you want to use with your applications. Catalogs are not provided by default. -** Each catalog must have an accessible `CatalogSource` added to a cluster, so that the OLM catalog Operator can use the catalog for content. -* You must use the CLI to conduct OLM activities with {microshift-short}. The console, software catalog, and catalog management GUIs are not available. -** Use the link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/cli_tools/opm-cli#cli-opm-install[Operator Package Manager `opm` CLI] with network-connected clusters, or for building catalogs for custom Operators that use an internal registry. -** To mirror your catalogs and Operators for disconnected or offline clusters, install link:https://docs.openshift.com/container-platform/{ocp-version}/installing/disconnected_install/installing-mirroring-disconnected.html#installation-oc-mirror-installing-plugin_installing-mirroring-disconnected[the oc-mirror OpenShift CLI plugin]. +** Each catalog must have an accessible `CatalogSource` added to a node, so that the OLM catalog Operator can use the catalog for content. +* You must use the CLI to conduct OLM activities with {microshift-short}. The console and OperatorHub GUIs are not available. +** Use the link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/cli_tools/opm-cli#cli-opm-install[Operator Package Manager `opm` CLI] with a network-connected node, or for building catalogs for custom Operators that use an internal registry. +** To mirror your catalogs and Operators for disconnected or offline nodes, install link:https://docs.openshift.com/container-platform/{ocp-version}/installing/disconnected_install/installing-mirroring-disconnected.html#installation-oc-mirror-installing-plugin_installing-mirroring-disconnected[the oc-mirror OpenShift CLI plugin]. [IMPORTANT] ==== @@ -27,7 +27,7 @@ Before using an Operator, verify with the provider that the Operator is supporte [id="microshift-installing-olm-options_{context}"] == Determining your OLM installation type -You can install the OLM package manager for use with {microshift-short} 4.15 or newer versions. There are different ways to install OLM for {microshift-short} clusters, depending on your use case. +You can install the OLM package manager for use with {microshift-short} 4.15 or newer versions. There are different ways to install OLM for a {microshift-short} node, depending on your use case. * You can install the `microshift-olm` RPM at the same time you install the {microshift-short} RPM on {op-system-base-full}. * You can install the `microshift-olm` on an existing {microshift-short} {product-version}. Restart the {microshift-short} service after installing OLM for the changes to apply. @@ -59,5 +59,5 @@ include::modules/microshift-olm-deploy-ops-spec-ns.adoc[leveloffset=+2] //additional resources for working with operators after deployment [role="_additional-resources"] .Additional resources -* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/operators/administrator-tasks#olm-upgrading-operators[Updating installed Operators] -* link:https://access.redhat.com/documentation/en-us/openshift_container_platform/{ocp-version}/html/operators/administrator-tasks#olm-deleting-operator-from-a-cluster-using-cli_olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster using the CLI] +* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/operators/administrator-tasks#olm-upgrading-operators[Updating installed Operators] +* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/operators/administrator-tasks#olm-deleting-operator-from-a-cluster-using-cli_olm-deleting-operators-from-a-cluster[Deleting Operators from a cluster using the CLI] diff --git a/microshift_running_apps/microshift_operators/microshift-operators.adoc b/microshift_running_apps/microshift_operators/microshift-operators.adoc index e665d028fe5d..cf2b371bb064 100644 --- a/microshift_running_apps/microshift_operators/microshift-operators.adoc +++ b/microshift_running_apps/microshift_operators/microshift-operators.adoc @@ -6,16 +6,16 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -You can use Operators with {microshift-short} to create applications that monitor the running services in your cluster. Operators can manage applications and their resources, such as deploying a database or message bus. As customized software running inside your cluster, Operators can be used to implement and automate common operations. +You can use Operators with {microshift-short} to create applications that monitor the running services in your node. Operators can manage applications and their resources, such as deploying a database or message bus. As customized software running inside your node, Operators can be used to implement and automate common operations. Operators offer a more localized configuration experience and integrate with Kubernetes APIs and CLI tools such as `kubectl` and `oc`. Operators are designed specifically for your applications. Operators enable you to configure components instead of modifying a global configuration file. {microshift-short} applications are generally expected to be deployed in static environments. However, Operators are available if helpful in your use case. To determine the compatibility of an Operator with {microshift-short}, check the Operator documentation. [id="microshift-operators-installation-paths_{context}"] -== How to use Operators with {microshift-short} clusters +== How to use Operators with a {microshift-short} node -There are two ways to use Operators for your {microshift-short} clusters: +There are two ways to use Operators for your {microshift-short} node: [id="microshift-operators-paths-manifests_{context}"] === Manifests for Operators @@ -25,6 +25,6 @@ Operators can be installed and managed directly by using manifests. You can use [id="microshift-operators-paths-olm_{context}"] === Operator Lifecycle Manager for Operators -You can also install add-on Operators to a {microshift-short} cluster using Operator Lifecycle Manager (OLM). OLM can be used to manage both custom Operators and Operators that are widely available. Building catalogs is required to use OLM with {microshift-short}. +You can also install add-on Operators to a {microshift-short} node by using Operator Lifecycle Manager (OLM). OLM can be used to manage both custom Operators and Operators that are widely available. Building catalogs is required to use OLM with {microshift-short}. * For details, see xref:../../microshift_running_apps/microshift_operators/microshift-operators-olm.adoc#microshift-operators-olm[Using Operator Lifecycle Manager with {microshift-short}]. diff --git a/microshift_storage/index.adoc b/microshift_storage/index.adoc index d6105b302022..55edaa65c59d 100644 --- a/microshift_storage/index.adoc +++ b/microshift_storage/index.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -{microshift-short} supports multiple types of storage, both for on-premise and cloud providers. You can manage container storage for persistent and non-persistent data in a {product-title} cluster. +{microshift-short} supports multiple types of storage, both for on-premise and cloud providers. You can manage container storage for persistent and non-persistent data in a {microshift-short} node. [id="microshift-storage-types"] == Storage types @@ -21,7 +21,7 @@ Pods and containers are ephemeral or transient in nature and designed for statel [id="microshift-persistent-storage"] === Persistent storage -Stateful applications deployed in containers require persistent storage. {microshift-short} uses a pre-provisioned storage framework called persistent volumes (PV) to allow cluster administrators to provision persistent storage. The data inside these volumes can exist beyond the lifecycle of an individual pod. Developers can use persistent volume claims (PVCs) to request storage requirements. For persistent storage details, read xref:../microshift_storage/understanding-persistent-storage-microshift.adoc#understanding-persistent-storage-microshift[Understanding persistent storage]. +Stateful applications deployed in containers require persistent storage. {microshift-short} uses a pre-provisioned storage framework called persistent volumes (PV) to allow node administrators to provision persistent storage. The data inside these volumes can exist beyond the lifecycle of an individual pod. Developers can use persistent volume claims (PVCs) to request storage requirements. For persistent storage details, read xref:../microshift_storage/understanding-persistent-storage-microshift.adoc#understanding-persistent-storage-microshift[Understanding persistent storage]. [id="microshift-dynamic-provisioning-overview"] === Dynamic storage provisioning diff --git a/microshift_storage/microshift-storage-migration.adoc b/microshift_storage/microshift-storage-migration.adoc index bf0bad40df9b..e8c3d983d5ef 100644 --- a/microshift_storage/microshift-storage-migration.adoc +++ b/microshift_storage/microshift-storage-migration.adoc @@ -6,6 +6,6 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -Storage version migration is used to update existing objects in the cluster from their current version to the latest version. The Kube Storage Version Migrator embedded controller is used in {microshift-short} to migrate resources without having to recreate those resources. Either you or a controller can create a `StorageVersionMigration` custom resource (CR) that requests a migration through the Migrator Controller. +Storage version migration is used to update existing objects in the {microshift-short} node from their current version to the latest version. The Kube Storage Version Migrator embedded controller is used in {microshift-short} to migrate resources without having to re-create those resources. Either you or a controller can create a `StorageVersionMigration` custom resource (CR) that requests a migration through the Migrator Controller. include::modules/microshift-making-storage-migration-request.adoc[leveloffset=+1] diff --git a/microshift_storage/understanding-persistent-storage-microshift.adoc b/microshift_storage/understanding-persistent-storage-microshift.adoc index 145bc337fa1d..65444e080dfe 100644 --- a/microshift_storage/understanding-persistent-storage-microshift.adoc +++ b/microshift_storage/understanding-persistent-storage-microshift.adoc @@ -6,7 +6,7 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -Managing storage is a distinct problem from managing compute resources. {microshift-short} uses the Kubernetes persistent volume (PV) framework to allow cluster administrators to provision persistent storage for a cluster. Developers can use persistent volume claims (PVCs) to request PV resources without having specific knowledge of the underlying storage infrastructure. +Managing storage is a distinct problem from managing compute resources. {microshift-short} uses the Kubernetes persistent volume (PV) framework to allow {microshift-short} administrators to provision persistent storage for a node. Developers can use persistent volume claims (PVCs) to request PV resources without having specific knowledge of the underlying storage infrastructure. include::modules/microshift-control-permissions-security-context-constraints.adoc[leveloffset=+1] diff --git a/microshift_storage/volume-snapshots-microshift.adoc b/microshift_storage/volume-snapshots-microshift.adoc index 43e2c063daf7..064e8a9ddeb7 100644 --- a/microshift_storage/volume-snapshots-microshift.adoc +++ b/microshift_storage/volume-snapshots-microshift.adoc @@ -6,11 +6,11 @@ include::_attributes/attributes-microshift.adoc[] toc::[] -Cluster administrators can use volume snapshots to help protect against data loss by using the supported {microshift-short} logical volume manager storage (LVMS) Container Storage Interface (CSI) provider. Familiarity with xref:../microshift_storage/understanding-persistent-storage-microshift.adoc#persistent-volumes_understanding-persistent-storage-microshift[persistent volumes] is required. +{microshift-short} administrators can use volume snapshots to help protect against data loss by using the supported {microshift-short} logical volume manager storage (LVMS) Container Storage Interface (CSI) provider. Familiarity with xref:../microshift_storage/understanding-persistent-storage-microshift.adoc#persistent-volumes_understanding-persistent-storage-microshift[persistent volumes] is required. -A snapshot represents the state of the storage volume in a cluster at a particular point in time. Volume snapshots can also be used to provision new volumes. Snapshots are created as read-only logical volumes (LVs) located on the same device as the original data. +A snapshot represents the state of the storage volume in a node at a particular point in time. Volume snapshots can also be used to provision new volumes. Snapshots are created as read-only logical volumes (LVs) located on the same device as the original data. -A cluster administrator can complete the following tasks using CSI volume snapshots: +A {microshift-short} administrator can complete the following tasks by using CSI volume snapshots: * Create a snapshot of an existing persistent volume claim (PVC). * Back up a volume snapshot to a secure location. diff --git a/microshift_support/microshift-getting-cluster-id.adoc b/microshift_support/microshift-getting-cluster-id.adoc deleted file mode 100644 index 0aa8004fe9d7..000000000000 --- a/microshift_support/microshift-getting-cluster-id.adoc +++ /dev/null @@ -1,18 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -[id="microshift-getting-cluster-id"] -= Getting your cluster ID -include::_attributes/attributes-microshift.adoc[] -:context: microshift-getting-cluster-id - -toc::[] - -When providing information to Red{nbsp}Hat Support, it is helpful to provide the unique identifier of your cluster. For {microshift-short}, you can get your cluster ID manually by using the {oc-first} or by retrieving the ID from a file. - -[NOTE] -==== -A cluster ID is created only after the {microshift-short} service runs for the first time after installation. -==== - -include::modules/microshift-get-cluster-id-kubesystem.adoc[leveloffset=+1] - -include::modules/microshift-get-nonrunning-cluster-id-kubesystem.adoc[leveloffset=+1] \ No newline at end of file diff --git a/microshift_support/microshift-getting-node-id.adoc b/microshift_support/microshift-getting-node-id.adoc new file mode 100644 index 000000000000..ef72d982d447 --- /dev/null +++ b/microshift_support/microshift-getting-node-id.adoc @@ -0,0 +1,18 @@ +:_mod-docs-content-type: ASSEMBLY +[id="microshift-getting-node-id"] += Getting your node ID +include::_attributes/attributes-microshift.adoc[] +:context: microshift-getting-node-id + +toc::[] + +When providing information to Red{nbsp}Hat Support, it is helpful to provide the unique identifier of your node. For {microshift-short}, you can get your node ID manually by using the {oc-first} or by retrieving the ID from a file. + +[NOTE] +==== +A node ID is created only after the {microshift-short} service runs for the first time after installation. +==== + +include::modules/microshift-get-node-id-kubesystem.adoc[leveloffset=+1] + +include::modules/microshift-get-nonrunning-node-id-kubesystem.adoc[leveloffset=+1] diff --git a/microshift_support/microshift-remote-cluster-monitoring.adoc b/microshift_support/microshift-remote-node-monitoring.adoc similarity index 51% rename from microshift_support/microshift-remote-cluster-monitoring.adoc rename to microshift_support/microshift-remote-node-monitoring.adoc index 7a7d83a860da..0a06764a4213 100644 --- a/microshift_support/microshift-remote-cluster-monitoring.adoc +++ b/microshift_support/microshift-remote-node-monitoring.adoc @@ -1,12 +1,12 @@ :_mod-docs-content-type: ASSEMBLY -[id="microshift-remote-cluster-monitoring"] -= Remote health monitoring with a connected cluster +[id="microshift-remote-node-monitoring"] += Remote health monitoring with a connected node include::_attributes/attributes-microshift.adoc[] -:context: microshift-remote-cluster-monitoring +:context: microshift-remote-node-monitoring toc::[] -Telemetry and configuration data about your cluster can be collected and reported to Red{nbsp}Hat. +Telemetry and configuration data about your node can be collected and reported to Red{nbsp}Hat. include::modules/microshift-about-remote-health-monitoring.adoc[leveloffset=+1] @@ -14,7 +14,8 @@ include::modules/microshift-info-collected-telemetry.adoc[leveloffset=+1] include::modules/microshift-opt-out-telemetry.adoc[leveloffset=+1] -[id="additional-resources_microshift-remote-cluster-monitoring_{context}"] +[role="_additional-resources"] +[id="additional-resources_microshift-remote-node-monitoring_{context}"] == Additional resources -* xref:../microshift_configuring/microshift-config-snippets.adoc#microshift-config-snippets[Using configuration snippets] \ No newline at end of file +* xref:../microshift_configuring/microshift-config-snippets.adoc#microshift-config-snippets[Using configuration snippets] diff --git a/microshift_troubleshooting/microshift-troubleshoot-cluster.adoc b/microshift_troubleshooting/microshift-troubleshoot-cluster.adoc deleted file mode 100644 index b59add857e1f..000000000000 --- a/microshift_troubleshooting/microshift-troubleshoot-cluster.adoc +++ /dev/null @@ -1,11 +0,0 @@ -:_mod-docs-content-type: ASSEMBLY -[id="microshift-troubleshoot-cluster"] -= Troubleshooting a cluster -include::_attributes/attributes-microshift.adoc[] -:context: microshift-troubleshoot-cluster - -toc::[] - -To begin troubleshooting a {microshift-short} cluster, first access the cluster status. - -include::modules/microshift-check-cluster-status.adoc[leveloffset=+1] \ No newline at end of file diff --git a/microshift_troubleshooting/microshift-troubleshoot-node.adoc b/microshift_troubleshooting/microshift-troubleshoot-node.adoc new file mode 100644 index 000000000000..c0ea34d8e87d --- /dev/null +++ b/microshift_troubleshooting/microshift-troubleshoot-node.adoc @@ -0,0 +1,11 @@ +:_mod-docs-content-type: ASSEMBLY +[id="microshift-troubleshoot-node"] += Troubleshooting a node +include::_attributes/attributes-microshift.adoc[] +:context: microshift-troubleshoot-node + +toc::[] + +To begin troubleshooting a {microshift-short} node, first access the node status. + +include::modules/microshift-check-node-status.adoc[leveloffset=+1] diff --git a/microshift_updating/microshift-update-options.adoc b/microshift_updating/microshift-update-options.adoc index 5afb71499eec..7e0854c10b75 100644 --- a/microshift_updating/microshift-update-options.adoc +++ b/microshift_updating/microshift-update-options.adoc @@ -87,7 +87,7 @@ You can update {op-system-ostree} or {op-system-base} and update {microshift-sho [id="microshift-update-options-edge-to-image_{context}"] == Migrating {microshift-short} from {op-system-ostree} to {op-system-image} -Starting with {microshift-short} 4.19, you can migrate your {microshift-short} cluster from {op-system-ostree} to {op-system-image} if the versions are compatible. Check compatibilities before beginning a migration. See the {op-system-base} documentation for instructions to migrate your image-based {op-system-base} system. +Starting with {microshift-short} 4.19, you can migrate your {microshift-short} node from {op-system-ostree} to {op-system-image} if the versions are compatible. Check compatibilities before beginning a migration. See the {op-system-base} documentation for instructions to migrate your image-based {op-system-base} system. //RHEL docs are coming soon //additional resources for updating RHEL and MicroShift diff --git a/modules/microshift-about-remote-health-monitoring.adoc b/modules/microshift-about-remote-health-monitoring.adoc index 6b0155d6c9f3..a509b520fd60 100644 --- a/modules/microshift-about-remote-health-monitoring.adoc +++ b/modules/microshift-about-remote-health-monitoring.adoc @@ -1,14 +1,14 @@ // Module included in the following assemblies: // -// microshift_support/microshift-remote-cluster-monitoring.adoc +// microshift_support/microshift-remote-node-monitoring.adoc :_mod-docs-content-type: CONCEPT [id="microshift-about-remote-health-monitoring_{context}"] = About remote health monitoring with {microshift-short} -Remote health monitoring is conducted in {microshift-short} by the collection of telemetry and configuration data about your cluster that is reported to Red{nbsp}Hat with the Telemeter API. A cluster that reports Telemetry to Red{nbsp}Hat is considered a _connected cluster_. +Remote health monitoring is conducted in {microshift-short} by the collection of telemetry and configuration data about your node that is reported to Red{nbsp}Hat with the Telemeter API. A node that reports Telemetry to Red{nbsp}Hat is considered a _connected node_. -*Telemetry* is the term that Red{nbsp}Hat uses to describe the information being sent to Red{nbsp}Hat by the {microshift-short} Telemeter API. Lightweight attributes are sent from a connected cluster to Red{nbsp}Hat to monitor the health of clusters. +*Telemetry* is the term that Red{nbsp}Hat uses to describe the information being sent to Red{nbsp}Hat by the {microshift-short} Telemeter API. Lightweight attributes are sent from a connected node to Red{nbsp}Hat to monitor the health of a node. .Telemetry benefits @@ -18,11 +18,11 @@ Telemetry provides the following benefits: * *Targeted prioritization of new features and functionality*. The data collected provides information about system capabilities and usage characteristics. With this information, Red{nbsp}Hat can focus on developing the new features and functionality that have the greatest impact for our customers. -Telemetry sends a carefully chosen subset of the cluster monitoring metrics to Red{nbsp}Hat. The Telemeter API fetches the metrics values every hour and uploads the data to Red{nbsp}Hat. This stream of data is used by Red{nbsp}Hat to monitor a cluster over time. +Telemetry sends a carefully chosen subset of the node monitoring metrics to Red{nbsp}Hat. The Telemeter API fetches the metrics values every hour and uploads the data to Red{nbsp}Hat. This stream of data is used by Red{nbsp}Hat to monitor nodes over time. -This debugging information is available to Red{nbsp}Hat Support and Engineering teams with the same restrictions as accessing data reported through support cases. All _connected cluster_ information is used by Red{nbsp}Hat to help make {microshift-short} better. +This debugging information is available to Red{nbsp}Hat Support and Engineering teams with the same restrictions as accessing data reported through support cases. All _connected node_ information is used by Red{nbsp}Hat to help make {microshift-short} better. [NOTE] ==== -{microshift-short} does not support Prometheus. To view the Telemetry gathered from your cluster, you must contact Red{nbsp}Hat Support. +{microshift-short} does not support Prometheus. To view the Telemetry gathered from your node, you must contact Red{nbsp}Hat Support. ==== \ No newline at end of file diff --git a/modules/microshift-about-sos-reports.adoc b/modules/microshift-about-sos-reports.adoc index 77d809ffec52..b66c76574b26 100644 --- a/modules/microshift-about-sos-reports.adoc +++ b/modules/microshift-about-sos-reports.adoc @@ -6,9 +6,8 @@ [id="about-microshift-sos-reports_{context}"] = About sos reports -The `sos` tool is composed of different plugins that help you gather information from different applications. A {microshift-short}-specific plugin has been added from sos version 4.5.1, and it can gather the following data: +The `sos` tool is composed of different plugins that help you gather information from different applications. A {microshift-short}-specific plugin from sos version 4.5.1 can gather the following data: * {microshift-short} configuration and version -* YAML output for cluster-wide and system namespaced resources +* YAML output for node and system namespaced resources * OVN-Kubernetes information - diff --git a/modules/microshift-applying-manifests-example.adoc b/modules/microshift-applying-manifests-example.adoc index 56552ac862b3..b16dd134cbd5 100644 --- a/modules/microshift-applying-manifests-example.adoc +++ b/modules/microshift-applying-manifests-example.adoc @@ -6,7 +6,7 @@ [id="microshift-applying-manifests-example_{context}"] = Using manifests example -This example demonstrates automatic deployment of a BusyBox container using `kustomize` manifests in the `/etc/microshift/manifests` directory. +This example demonstrates automatic deployment of a BusyBox container by using `kustomize` manifests in the `/etc/microshift/manifests` directory. .Procedure . Create the BusyBox manifest files by running the following commands: diff --git a/modules/microshift-arch-design.adoc b/modules/microshift-arch-design.adoc index 363cf4ab329e..1e28c8ffae4b 100644 --- a/modules/microshift-arch-design.adoc +++ b/modules/microshift-arch-design.adoc @@ -8,7 +8,7 @@ {microshift-short} is a single-node container orchestration runtime designed to extend the benefits of using containers for running applications to low-resource edge environments. Because {microshift-short} is primarily a platform for deploying applications, only the APIs and features essential to operating in edge and small form factor computing environments are included. -For example, {microshift-short} has only the following Kubernetes cluster capabilities: +For example, {microshift-short} has only the following Kubernetes node capabilities: * Networking * Ingress @@ -22,27 +22,27 @@ For example, {microshift-short} has only the following Kubernetes cluster capabi To optimize your deployments, use {microshift-short} with a compatible operating system, such as {op-system-ostree-first}. Using {microshift-short} and {op-system-ostree-first} together forms {op-system-bundle}. Virtual machines are handled by the operating system in {microshift-short} deployments. .{product-title} as part of {op-system-bundle}. -image::311_RHDevice_Edge_Overview_0223_1.png[<{product-title} is tasked with only the Kubernetes cluster services networking, ingress, storage, helm, with additional Kubernetes functions of orchestration and security, as the following diagram illustrates.>] +image::311_RHDevice_Edge_Overview_0223_1.png[<{product-title} is tasked with only the Kubernetes node services networking, ingress, storage, helm, with additional Kubernetes functions of orchestration and security, as the following diagram illustrates.>] -The following operational differences from {oke} can help you understand where {microshift-short} can be deployed: +The following operational differences from {oke} can help you understand where you can deploy {microshift-short}: [id="microshift-differences-oke_{context}"] == Key differences from {oke} * Devices with {microshift-short} installed are self-managing -* Compatible with RPM-OStree-based systems +* Compatible with `rpm-ostree`-based systems * Uses only the APIs needed for essential functions, such as security and runtime controls -* Enables a subset of commands from the OpenShift CLI (`oc`) tool +* Enables a subset of commands from the {oc-first} tool * Does not support workload high availability (HA) or horizontal scalability with the addition of worker nodes .{product-title} differences from {oke}. -image::311_RHDevice_Edge_Overview_0223_2.png[<{microshift-short} is tasked with only the Kubernetes cluster capabilities of networking, ingress, storage, helm, with the additional Kubernetes functions of orchestration and security, as the following diagram illustrates.>] +image::311_RHDevice_Edge_Overview_0223_2.png[<{microshift-short} is tasked with only the Kubernetes node capabilities of networking, ingress, storage, helm, with the additional Kubernetes functions of orchestration and security, as the following diagram illustrates.>] -The figure "{product-title} differences from {oke}" shows that {oke} has the same cluster capabilities as {product-title}, and adds the following information: +The figure "{product-title} differences from {oke}" shows that {oke} has the same cluster capabilities as a {product-title} node, and adds the following information: * Install * Over-the-air updates -* Cluster Operators +* Operators * Operator Lifecycle Manager * Monitoring * Logging diff --git a/modules/microshift-audit-logs-config-intro.adoc b/modules/microshift-audit-logs-config-intro.adoc index 50d913be662b..8c3bcdbee18c 100644 --- a/modules/microshift-audit-logs-config-intro.adoc +++ b/modules/microshift-audit-logs-config-intro.adoc @@ -6,7 +6,7 @@ [id="microshift-audit-logs-config-intro_{context}"] = About setting limits on audit log files -Controlling the rotation and retention of the {microshift-short} audit log file by using configuration values helps keep the limited storage capacities of far-edge devices from being exceeded. On such devices, logging data accumulation can limit host system or cluster workloads, potentially causing the device stop working. Setting audit log policies can help ensure that critical processing space is continually available. +Controlling the rotation and retention of the {microshift-short} audit log file by using configuration values helps keep the limited storage capacities of far-edge devices from being exceeded. On such devices, logging data accumulation can limit host system or node workloads, potentially causing the device stop working. Setting audit log policies can help ensure that critical processing space is continually available. The values you set to limit {microshift-short} audit logs enable you to enforce the size, number, and age limits of audit log backups. Field values are processed independently of one another and without prioritization. @@ -38,5 +38,5 @@ If you do not specify a value for a field, the default value is used. If you rem [IMPORTANT] ==== -You must configure audit log retention and rotation in {op-system-base-full} for logs that are generated by application pods. These logs print to the console and are saved. Ensure that your log preferences are configured for the {op-system-base} `/var/log/audit/audit.log` file to maintain {microshift-short} cluster health. +You must configure audit log retention and rotation in {op-system-base-full} for logs that are generated by application pods. These logs print to the console and are saved. Ensure that your log preferences are configured for the {op-system-base} `/var/log/audit/audit.log` file to maintain {microshift-short} node health. ==== \ No newline at end of file diff --git a/modules/microshift-ca-adding-bundle.adoc b/modules/microshift-ca-adding-bundle.adoc index 459defdfc093..5214652f61f3 100644 --- a/modules/microshift-ca-adding-bundle.adoc +++ b/modules/microshift-ca-adding-bundle.adoc @@ -6,4 +6,4 @@ [id="microshift-ca-adding-bundle_{context}"] = Adding a certificate authority bundle -{microshift-short} uses the host trust bundle when clients evaluate server certificates. You can also use a customized security certificate chain to improve the compatibility of your endpoint certificates with clients specific to your deployments. To do this, you can add a certificate authority (CA) bundle with root and intermediate certificates to the {op-system-ostree-first} system-wide trust store. +{microshift-short} uses the host trust bundle when clients evaluate server certificates. You can also use a customized security certificate chain to improve the compatibility of your endpoint certificates with clients specific to your deployments. To do this, you can add a certificate authority (CA) bundle with root and intermediate certificates to the {op-system-ostree-first} system-wide truststore. diff --git a/modules/microshift-check-cluster-status.adoc b/modules/microshift-check-node-status.adoc similarity index 73% rename from modules/microshift-check-cluster-status.adoc rename to modules/microshift-check-node-status.adoc index 530bf0fe6543..73d9afdb38c5 100644 --- a/modules/microshift-check-cluster-status.adoc +++ b/modules/microshift-check-node-status.adoc @@ -1,15 +1,16 @@ //Module included in the following assemblies: // -//* microshift_troubleshooting/microshift-troubleshoot-cluster +//* microshift_troubleshooting/microshift-troubleshoot-node :_mod-docs-content-type: PROCEDURE -[id="microshift-check-cluster-status_{context}"] -= Checking the status of a cluster +[id="microshift-check-node-status_{context}"] += Checking the status of a node -You can check the status of a {microshift-short} cluster or see active pods. Given in the following procedure are three different commands you can use to check cluster status. You can choose to run one, two, or all commands to help you get the information you need to troubleshoot the cluster. +You can check the status of a {microshift-short} node or see active pods. You can choose to run any or all of the following commands to help you get the information you need to troubleshoot the node. .Procedure -* Check the system status, which returns the cluster status, by running the following command: + +* Check the system status, which returns the node status, by running the following command: + [source,terminal] ---- diff --git a/modules/microshift-cli-oc-about.adoc b/modules/microshift-cli-oc-about.adoc index 02ce5b7c4b3c..80a345b3e82b 100644 --- a/modules/microshift-cli-oc-about.adoc +++ b/modules/microshift-cli-oc-about.adoc @@ -14,5 +14,5 @@ With the OpenShift command-line interface (CLI), the `oc` command, you can deplo [NOTE] ==== -A `kubeconfig` file must exist for the cluster to be accessible. The values are applied from built-in default values or a `config.yaml`, if one was created. +A `kubeconfig` file must exist for the node to be accessible. The values are applied from built-in default values or a `config.yaml`, if you created one. ==== diff --git a/modules/microshift-cni-multus-nad-additional-network.adoc b/modules/microshift-cni-multus-nad-additional-network.adoc index 6d2adee4a4aa..b1d90d64a03c 100644 --- a/modules/microshift-cni-multus-nad-additional-network.adoc +++ b/modules/microshift-cni-multus-nad-additional-network.adoc @@ -16,12 +16,12 @@ If you use `bridge` and the `dhcp` IPAM, a DHCP server listening on the bridged .Prerequisites * The {microshift-short} Multus CNI is installed. -* The OpenShift CLI (`oc`) is installed. -* The cluster is running. +* The {oc-first} is installed. +* {microshift-short} is running. .Procedure -. Optional: Verify that the {microshift-short} cluster is running with the Multus CNI by running the following command: +. Optional: Verify that the {microshift-short} node is running with the Multus CNI by running the following command: + [source,terminal] ---- diff --git a/modules/microshift-con-understanding-generic-device-plugin.adoc b/modules/microshift-con-understanding-generic-device-plugin.adoc index c275ba6c1d15..abdb8e977618 100644 --- a/modules/microshift-con-understanding-generic-device-plugin.adoc +++ b/modules/microshift-con-understanding-generic-device-plugin.adoc @@ -6,7 +6,7 @@ [id="microshift-understanding-generic-device-plugin-con_{context}"] = Understanding the Generic Device Plugin -The Generic Device Plugin (GDP) is a Kubernetes device plugin that enables applications running in pods to access host devices such as serial ports, cameras, and sound cards securely. This capability is especially important for edge and IoT environments where direct hardware interaction is a common requirement. The GDP integrates with the kubelet to advertise available devices to the cluster and facilitate their allocation to pods without requiring elevated privileges within the container itself. +The Generic Device Plugin (GDP) is a Kubernetes device plugin that enables applications running in pods to access host devices such as serial ports, cameras, and sound cards securely. This capability is especially important for edge and IoT environments where direct hardware interaction is a common requirement. The GDP integrates with the kubelet to advertise available devices to the node and facilitate their allocation to pods without requiring elevated privileges within the container itself. The GDP is designed to handle devices that are initialized and managed by the operating system and do not require any special initialization procedures or drivers for a pod to use them. diff --git a/modules/microshift-config-parameters-table.adoc b/modules/microshift-config-parameters-table.adoc index 9c104aff5ef1..8a68130620b4 100644 --- a/modules/microshift-config-parameters-table.adoc +++ b/modules/microshift-config-parameters-table.adoc @@ -15,7 +15,7 @@ The following table explains {microshift-short} configuration YAML parameters an |`advertiseAddress` |`string` -|A string that specifies the IP address from which the API server is advertised to members of the cluster. The default value is calculated based on the address of the service network. +|A string that specifies the IP address from which the API server is advertised to members of the node. The default value is calculated based on the address of the service network. |`auditLog.maxFileAge` |`number` @@ -71,7 +71,7 @@ The following table explains {microshift-short} configuration YAML parameters an |`dns.baseDomain` |`valid domain` -|Base domain of the cluster. All managed DNS records are subdomains of this base. +|Base domain of the node. All managed DNS records are subdomains of this base. |`etcd.memoryLimitMB` |`number` @@ -147,7 +147,7 @@ When unspecified, the value defaults to `mrw`. |`generic.Device.Plugin.domain` |`string` -|Specifies the domain prefix with which devices are advertised and present in the cluster. For example, `device.microshift.io/serial`. The default value is `device.microshift.io`. +|Specifies the domain prefix with which devices are advertised and present in the node. For example, `device.microshift.io/serial`. The default value is `device.microshift.io`. |`generic.Device.Plugin.status` |`Enabled`, `Disabled` @@ -162,13 +162,13 @@ The secret must contain the following keys and data: * `tls.crt`: certificate file contents * `tls.key`: key file contents -If you do not set one of these values, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains` fields, and the generated CA for the certificate is automatically integrated with the truststore for the cluster. +If you do not set one of these values, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains` fields, and the generated CA for the certificate is automatically integrated with the truststore for the node. Any certificate in use is automatically integrated in the {microshift-short} OAuth server. |`ingress.clientTLS` |`AllowedSubjectPatterns`, `spec.clientTLS.ClientCA`, `spec.clientTLS.clientCertificatePolicy` -|Authenticates client access to the cluster and services. Mutual TLS authentication is enabled when using these settings. If you do not set values for the `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA` required subfields, client TLS is not enabled. +|Authenticates client access to the node and services. Mutual TLS authentication is enabled when using these settings. If you do not set values for the `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA` required subfields, client TLS is not enabled. //are the values in the config.yaml defaults? //if I don't want to use client TLS, do I leave all three subfields empty? diff --git a/modules/microshift-config-yaml-custom.adoc b/modules/microshift-config-yaml-custom.adoc index ab19c8468406..30be96631339 100644 --- a/modules/microshift-config-yaml-custom.adoc +++ b/modules/microshift-config-yaml-custom.adoc @@ -17,7 +17,7 @@ Restart {microshift-short} after changing any configuration settings to have the [id="microshift-yaml-custom-settings_{context}"] == Separate restarts -Applications and other optional services used with your {microshift-short} cluster might also need to be restarted separately to apply configuration changes throughout the cluster. For example, when making changes to certain networking settings, you must stop and restart service and application pods to apply those changes. See each procedure for the task you are completing for more information. +Applications and other optional services used with your {microshift-short} node might also need to be restarted separately to apply configuration changes throughout the node. For example, when making changes to certain networking settings, you must stop and restart service and application pods to apply those changes. See each procedure for the task you are completing for more information. [TIP] ==== diff --git a/modules/microshift-config-yaml.adoc b/modules/microshift-config-yaml.adoc index ea7be9f9989c..70873688c162 100644 --- a/modules/microshift-config-yaml.adoc +++ b/modules/microshift-config-yaml.adoc @@ -8,6 +8,6 @@ At startup, {microshift-short} checks the system-wide `/etc/microshift/` directory for a configuration file named `config.yaml`. If the configuration file does not exist in the directory, built-in default values are used to start the service. -You must use the {microshift-short} configuration file in combination with host and, sometimes, application and service settings. Ensure that you configure each function in tandem when you adjust settings for your {microshift-short} cluster. +You must use the {microshift-short} configuration file in combination with host and, sometimes, application and service settings. Ensure that you configure each function in tandem when you adjust settings for your {microshift-short} node. For your convenience, a `config.yaml.default` file ready for your inputs is automatically installed. diff --git a/modules/microshift-control-permissions-security-context-constraints.adoc b/modules/microshift-control-permissions-security-context-constraints.adoc index 18a43baaac31..0d7a4c2b338d 100644 --- a/modules/microshift-control-permissions-security-context-constraints.adoc +++ b/modules/microshift-control-permissions-security-context-constraints.adoc @@ -6,7 +6,7 @@ [id=microshift-control-permissions-security-context-constraints_{context}] = Control permissions with security context constraints -You can use security context constraints (SCCs) to control permissions for the pods in your cluster. These permissions determine the actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system. +You can use security context constraints (SCCs) to control permissions for the pods in your node. These permissions determine the actions that a pod can perform and what resources it can access. You can use SCCs to define a set of conditions that a pod must run with to be accepted into the system. For more information see link:https://docs.openshift.com/container-platform/4.16/authentication/managing-security-context-constraints.html[Managing security context constraints]. diff --git a/modules/microshift-creating-backups-auto-recovery.adoc b/modules/microshift-creating-backups-auto-recovery.adoc index 8e70d579d6fb..9147a07b48dd 100644 --- a/modules/microshift-creating-backups-auto-recovery.adoc +++ b/modules/microshift-creating-backups-auto-recovery.adoc @@ -6,11 +6,11 @@ [id="microshift-creating-backups-auto-recovery_{context}"] = Creating backups using the auto-recovery feature -Use the following procedure to create backups using automatic recovery options. +Use the following procedure to create backups by using automatic recovery options. [NOTE] ==== -Creating backups require stopping {microshift-short}, so you must determine the best time to stop {microshift-short}. +Creating backups require stopping {microshift-short}. You must decide on the best time to stop {microshift-short}. ==== .Prerequisites diff --git a/modules/microshift-custom-ca-cert-cleaning.adoc b/modules/microshift-custom-ca-cert-cleaning.adoc index 62bca2705060..59c656f38801 100644 --- a/modules/microshift-custom-ca-cert-cleaning.adoc +++ b/modules/microshift-custom-ca-cert-cleaning.adoc @@ -6,7 +6,7 @@ [id="microshift-custom-ca-certificates-cleaning_{context}"] = Cleaning up and recreating the custom certificates -To stop the {microshift-short} services, clean up the custom certificates and recreate the custom certificates, use the following steps. +To stop the {microshift-short} services, clean up the custom certificates and re-create the custom certificates, use the following steps. .Procedure diff --git a/modules/microshift-custom-ca-con.adoc b/modules/microshift-custom-ca-con.adoc index 10a3198c91b5..f27733c7a2e0 100644 --- a/modules/microshift-custom-ca-con.adoc +++ b/modules/microshift-custom-ca-con.adoc @@ -6,7 +6,7 @@ [id="microshift-custom-cas_{context}"] = Using custom certificate authorities for the {microshift-short} API server -When {microshift-short} starts, an internal {microshift-short} cluster certificate authority (CA) issues the default API server certificate. By default, clients outside of the cluster cannot verify the {microshift-short}-issued API server certificate. You can grant secure access and encrypt connections between the {microshift-short} API server and external clients. Replace the default certificate with a custom server certificate issued externally by a CA that clients trust. +When {microshift-short} starts, an internal {microshift-short} node certificate authority (CA) issues the default API server certificate. By default, clients outside of the node cannot verify the {microshift-short}-issued API server certificate. You can grant secure access and encrypt connections between the {microshift-short} API server and external clients. Replace the default certificate with a custom server certificate issued externally by a CA that clients trust. The following steps illustrate the workflow for customizing the API server certificate configuration in {microshift-short}: diff --git a/modules/microshift-custom-ca-proc.adoc b/modules/microshift-custom-ca-proc.adoc index ff544d120f4c..ea73909b11b8 100644 --- a/modules/microshift-custom-ca-proc.adoc +++ b/modules/microshift-custom-ca-proc.adoc @@ -16,7 +16,7 @@ Externally generated `kubeconfig` files are created in the `/var/lib/microshift/ .Prerequisites * The {oc-first} is installed. -* You have access to the cluster as a user with the cluster administration role. +* You have root access to the node. * The certificate authority has issued the custom certificates. * A {microshift-short} `/etc/microshift/config.yaml` configuration file exists. diff --git a/modules/microshift-custom-ca-reserved-names.adoc b/modules/microshift-custom-ca-reserved-names.adoc index 88d3ba69dd85..0e1c4cfd3ab7 100644 --- a/modules/microshift-custom-ca-reserved-names.adoc +++ b/modules/microshift-custom-ca-reserved-names.adoc @@ -18,7 +18,7 @@ The following certificate problems cause {microshift-short} to ignore certificat |Address |Type |Comment |`localhost` |DNS | |`127.0.0.1` |IP Address | -|`10.42.0.0` |IP Address |Cluster Network +|`10.42.0.0` |IP Address |Node Network |`10.43.0.0/16,10.44.0.0/16` |IP Address |Service Network |169.254.169.2/29 |IP Address |br-ex Network |`kubernetes.default.svc` |DNS | diff --git a/modules/microshift-deploying-a-load-balancer.adoc b/modules/microshift-deploying-a-load-balancer.adoc index fe6cd1574ff9..18866d982025 100644 --- a/modules/microshift-deploying-a-load-balancer.adoc +++ b/modules/microshift-deploying-a-load-balancer.adoc @@ -10,8 +10,8 @@ The following example procedure uses the node IP address as the external IP addr .Prerequisites -* The OpenShift CLI (`oc`) is installed. -* You installed a cluster on an infrastructure configured with the OVN-Kubernetes network plugin. +* The {oc-first} is installed. +* You installed a node on an infrastructure configured with the OVN-Kubernetes network plugin. * The `KUBECONFIG` environment variable is set. .Procedure @@ -158,7 +158,7 @@ nginx LoadBalancer 10.43.183.104 192.168.1.241 81:32434/TCP 2m .Verification -The following command forms five connections to the example `nginx` application using the external IP address of the `LoadBalancer` service configuration. The result of the command is a list of those server IP addresses. +The following command forms five connections to the example `nginx` application by using the external IP address of the `LoadBalancer` service configuration. The result of the command is a list of those server IP addresses. * Verify that the load balancer sends requests to all the running applications by running the following command: + diff --git a/modules/microshift-disabling-lvms-csi-driver.adoc b/modules/microshift-disabling-lvms-csi-driver.adoc index 798181db47b7..8b8ea1a8bcd9 100644 --- a/modules/microshift-disabling-lvms-csi-driver.adoc +++ b/modules/microshift-disabling-lvms-csi-driver.adoc @@ -7,16 +7,11 @@ [id="microshift-disabling-lvms-csi-driver_{context}"] = Disabling deployments that run the CSI driver implementations -Use the following procedure to disable installation of the CSI implementation pods. +Use the following procedure to disable installation of the CSI implementation pods. {microshift-short} does not delete CSI driver implementation pods. You must configure {microshift-short} to disable installation of the CSI driver implementation pods during the startup process. [IMPORTANT] ==== -This procedure is for users who are defining the configuration file before installing and running {microshift-short}. If {microshift-short} is already started then CSI driver implementation will be running. Users must manually remove it by following the uninstallation instructions. -==== - -[NOTE] -==== -{microshift-short} will not delete CSI driver implementation pods. You must configure {microshift-short} to disable installation of the CSI driver implementation pods during the startup process. +This procedure is for defining the configuration file before installing and running {microshift-short}. If {microshift-short} is already started, then the CSI driver implementation is running. You must manually remove it by following the uninstallation instructions. ==== .Procedure diff --git a/modules/microshift-disabling-uninstalling-lvms-csi-snapshot.adoc b/modules/microshift-disabling-uninstalling-lvms-csi-snapshot.adoc index 7ccc9389be67..9afb2a7e36da 100644 --- a/modules/microshift-disabling-uninstalling-lvms-csi-snapshot.adoc +++ b/modules/microshift-disabling-uninstalling-lvms-csi-snapshot.adoc @@ -14,7 +14,7 @@ You can reduce the use of runtime resources such as RAM, CPU, and storage by rem [IMPORTANT] ==== -Automated uninstallation is not supported as this can cause orphaning of the provisioned volumes. Without the LVMS CSI driver, the cluster does not have knowledge of the underlying storage interface and cannot perform provisioning and deprovisioning or mounting and unmounting operations. +Automated uninstallation is not supported as this can cause orphaning of the provisioned volumes. Without the LVMS CSI driver, the node does not detect the underlying storage interface and cannot perform provisioning and deprovisioning or mounting and unmounting operations. ==== [NOTE] diff --git a/modules/microshift-disconnected-host-con.adoc b/modules/microshift-disconnected-host-con.adoc index 1351d20f5a40..7b4385dcc823 100644 --- a/modules/microshift-disconnected-host-con.adoc +++ b/modules/microshift-disconnected-host-con.adoc @@ -6,13 +6,13 @@ [id="microshift-disconnected-host-preparation_{context}"] = Preparing networking for fully disconnected hosts -Use the procedure that follows to start and run {microshift-short} clusters on devices running fully disconnected operating systems. A {microshift-short} host is considered fully disconnected if it has no external network connectivity. +Use the procedure that follows to start and run {microshift-short} nodes on devices running fully disconnected operating systems. A {microshift-short} host is considered fully disconnected if it has no external network connectivity. Typically this means that the device does not have an attached network interface controller (NIC) to provide a subnet. These steps can also be completed on a host with a NIC that is removed after setup. You can also automate these steps on a host that does not have a NIC by using the `%post` phase of a Kickstart file. [IMPORTANT] ==== -Configuring networking settings for disconnected environments is necessary because {microshift-short} requires a network device to support cluster communication. To meet this requirement, you must configure {microshift-short} networking settings to use the "fake" IP address you assign to the system loopback device during setup. +Configuring networking settings for disconnected environments is necessary because {microshift-short} requires a network device to support node communication. To meet this requirement, you must configure {microshift-short} networking settings to use the "fake" IP address you assign to the system loopback device during setup. ==== [id="microshift-disconnected-host-procedure-summary_{context}"] @@ -35,4 +35,4 @@ For the changes to take effect:: * Disable the default NIC if attached. * Restart the host or device. -After starting, {microshift-short} runs using the loopback device for within-cluster communication. +After starting, {microshift-short} runs using the loopback device for intra-node communication. diff --git a/modules/microshift-disconnected-host-procedure.adoc b/modules/microshift-disconnected-host-procedure.adoc index 5b8845189320..77e7ddc5973a 100644 --- a/modules/microshift-disconnected-host-procedure.adoc +++ b/modules/microshift-disconnected-host-procedure.adoc @@ -10,14 +10,14 @@ To configure the networking settings for running {microshift-short} on a fully d .Prerequisites * RHEL 9 or newer. -* {microshift-short} 4.14 or newer. +* {microshift-short} 4.16 or newer. * Access to the host CLI. * A valid IP address chosen to avoid both internal and potential future external IP conflicts when running {microshift-short}. * {microshift-short} networking settings are set to defaults. [IMPORTANT] ==== -The following procedure is for use cases in which access to the {microshift-short} cluster is not required after devices are deployed in the field. There is no remote cluster access after the network connection is removed. +The following procedure is for use cases in which access to the {microshift-short} node is not required after devices are deployed in the field. There is no remote node access after the network connection is removed. ==== .Procedure @@ -77,7 +77,7 @@ node: EOF ---- -. {microshift-short} is now ready to use the loopback device for cluster communications. Finish preparing the device for offline use. +. {microshift-short} is now ready to use the loopback device for intra-node communications. Finish preparing the device for offline use. .. If the device currently has a NIC attached, disconnect the device from the network. .. Shut down the device and disconnect the NIC. @@ -89,13 +89,13 @@ EOF ---- $ sudo systemctl reboot <1> ---- -<1> This step restarts the cluster. Wait for the greenboot health check to report the system healthy before implementing verification. +<1> This step restarts the node. Wait for the greenboot health check to report the system healthy before implementing verification. .Verification -At this point, network access to the {microshift-short} host has been severed. If you have access to the host terminal, you can use the host CLI to verify that the cluster has started in a stable state. +At this point, network access to the {microshift-short} host has been severed. If you have access to the host terminal, you can use the host CLI to verify that the node has started in a stable state. -. Verify that the {microshift-short} cluster is running by entering the following commands: +. Verify that the {microshift-short} node is running by entering the following commands: + [source,terminal] ---- diff --git a/modules/microshift-exposed-audit-ports-loadbalancer.adoc b/modules/microshift-exposed-audit-ports-loadbalancer.adoc index 318606228301..b48a7634fd73 100644 --- a/modules/microshift-exposed-audit-ports-loadbalancer.adoc +++ b/modules/microshift-exposed-audit-ports-loadbalancer.adoc @@ -4,10 +4,9 @@ :_mod-docs-content-type: PROCEDURE [id="microshift-exposed-audit-ports-loadbalancer_{context}"] - = NodePort and LoadBalancer services -OVN-Kubernetes opens host ports for `NodePort` and `LoadBalancer` service types. These services add iptables rules that take the ingress traffic from the host port and forwards it to the clusterIP. Logs for the `NodePort` and `LoadBalancer` services are presented in the following examples: +OVN-Kubernetes opens host ports for `NodePort` and `LoadBalancer` service types. These services add iptables rules that take the ingress traffic from the host port and forwards it to the node IP address. Logs for the `NodePort` and `LoadBalancer` services are presented in the following examples: .Procedure diff --git a/modules/microshift-fips-rpm-system.adoc b/modules/microshift-fips-rpm-system.adoc index 392af8ff752c..2a5d3b8a4002 100644 --- a/modules/microshift-fips-rpm-system.adoc +++ b/modules/microshift-fips-rpm-system.adoc @@ -14,7 +14,7 @@ Using FIPS with {microshift-short} requires enabling the cryptographic module se + [IMPORTANT] ==== -Because FIPS must be enabled before the operating system that your cluster uses starts for the first time, you cannot enable FIPS after you deploy a cluster. +Because FIPS must be enabled before the operating system that your node uses starts for the first time, you cannot enable FIPS after you deploy a node. ==== * {microshift-short} uses a FIPS-compatible Golang compiler. diff --git a/modules/microshift-firewall-known-issue.adoc b/modules/microshift-firewall-known-issue.adoc index e566c541662f..723db787cc88 100644 --- a/modules/microshift-firewall-known-issue.adoc +++ b/modules/microshift-firewall-known-issue.adoc @@ -6,4 +6,4 @@ [id="microshift-firewall-known-issue_{context}"] = Known firewall issue -* To avoid breaking traffic flows with a firewall reload or restart, execute firewall commands before starting {op-system-base-full}. The CNI driver in {microshift-short} makes use of iptable rules for some traffic flows, such as those using the NodePort service. The iptable rules are generated and inserted by the CNI driver, but are deleted when the firewall reloads or restarts. The absence of the iptable rules breaks traffic flows. If firewall commands have to be executed after {microshift-short} is running, manually restart `ovnkube-master` pod in the `openshift-ovn-kubernetes` namespace to reset the rules controlled by the CNI driver. +To avoid breaking traffic flows with a firewall reload or restart, run firewall commands before starting {op-system-base-full}. The CNI driver in {microshift-short} makes use of iptable rules for some traffic flows, such as those using the NodePort service. The iptable rules are generated and inserted by the CNI driver, but are deleted when the firewall reloads or restarts. The absence of the iptable rules breaks traffic flows. If firewall commands have to run after {microshift-short} is started, manually restart `ovnkube-master` pod in the `openshift-ovn-kubernetes` namespace to reset the rules controlled by the CNI driver. diff --git a/modules/microshift-firewall-req-settings.adoc b/modules/microshift-firewall-req-settings.adoc index 96c635237c22..64beba059d8d 100644 --- a/modules/microshift-firewall-req-settings.adoc +++ b/modules/microshift-firewall-req-settings.adoc @@ -6,7 +6,7 @@ [id="microshift-firewall-req-settings_{context}"] = Required firewall settings -An IP address range for the cluster network must be enabled during firewall configuration. You can use the default values or customize the IP address range. If you choose to customize the cluster network IP address range from the default `10.42.0.0/16` setting, you must also use the same custom range in the firewall configuration. +An IP address range for the node network must be enabled during firewall configuration. You can use the default values or customize the IP address range. If you choose to customize the node network IP address range from the default `10.42.0.0/16` setting, you must also use the same custom range in the firewall configuration. .Firewall IP address settings [cols="3",options="header"] diff --git a/modules/microshift-firewall-update-for-service.adoc b/modules/microshift-firewall-update-for-service.adoc index 22209389bee9..36ef255ed67d 100644 --- a/modules/microshift-firewall-update-for-service.adoc +++ b/modules/microshift-firewall-update-for-service.adoc @@ -18,4 +18,4 @@ For `HostPort` pods, the CRI-O config sets up iptables DNAT (Destination Network These methods function for clients whether they are on the same host or on a remote host. The iptables rules, which are added by OVN-Kubernetes and CRI-O, attach to the PREROUTING and OUTPUT chains. The local traffic goes through the OUTPUT chain with the interface set to the `lo` type. The DNAT runs before it hits filler rules in the INPUT chain. -Because the {microshift-short} API server does not run in CRI-O, it is subject to the firewall configurations. You can open port 6443 in the firewall to access the API server in your {microshift-short} cluster. \ No newline at end of file +Because the {microshift-short} API server does not run in CRI-O, it is subject to the firewall configurations. You can open port 6443 in the firewall to access the API server in your {microshift-short} node. \ No newline at end of file diff --git a/modules/microshift-gathering-sos-report.adoc b/modules/microshift-gathering-sos-report.adoc index 921804069ad7..b6801a107852 100644 --- a/modules/microshift-gathering-sos-report.adoc +++ b/modules/microshift-gathering-sos-report.adoc @@ -12,7 +12,7 @@ .Procedure -. Log into the failing host as a root user. +. Log in to the failing host as a root user. . Perform the debug report creation procedure by running the following command: + diff --git a/modules/microshift-get-cluster-id-kubesystem.adoc b/modules/microshift-get-node-id-kubesystem.adoc similarity index 57% rename from modules/microshift-get-cluster-id-kubesystem.adoc rename to modules/microshift-get-node-id-kubesystem.adoc index 6eb464afc3d7..7596474fb47c 100644 --- a/modules/microshift-get-cluster-id-kubesystem.adoc +++ b/modules/microshift-get-node-id-kubesystem.adoc @@ -1,16 +1,16 @@ // Module included in the following assemblies: // -// microshift_support/microshift-getting-cluster-id.adoc +// microshift_support/microshift-getting-node-id.adoc :_mod-docs-content-type: PROCEDURE -[id="microshift-get-cluster-id-kubesystem_{context}"] -= Getting the cluster ID of a running cluster +[id="microshift-get-node-id-kubesystem_{context}"] += Getting the node ID of a running node -Use either the of the following steps to get the ID of a running cluster. +Use either the of the following steps to get the ID of a running node. .Procedure -* Get the ID of a running cluster using `oc get` by entering the following command: +* Get the ID of a running node using `oc get` by entering the following command: + [source,terminal] ---- @@ -23,7 +23,7 @@ $ oc get namespaces kube-system -o jsonpath={.metadata.uid} 7cf13853-68f4-454e-8f5c-1af748cbfb1a ---- -* Get the ID of a running cluster by retrieving it from the `cluster-id` file by entering the following command: +* Get the ID of a running node by retrieving it from the `cluster-id` file by entering the following command: + [source,terminal] ---- diff --git a/modules/microshift-get-nonrunning-cluster-id-kubesystem.adoc b/modules/microshift-get-nonrunning-cluster-id-kubesystem.adoc deleted file mode 100644 index 1e80886d2d57..000000000000 --- a/modules/microshift-get-nonrunning-cluster-id-kubesystem.adoc +++ /dev/null @@ -1,24 +0,0 @@ -// Module included in the following assemblies: -// -// microshift_support/microshift-getting-cluster-id.adoc - -:_mod-docs-content-type: PROCEDURE -[id="microshift-get-nonrunning-cluster-id-kubesystem_{context}"] -= Getting the cluster ID of a stopped cluster - -For a cluster that ran before, but is not running now, you can get the cluster ID from the `cluster-id` file in the `/var/lib/microshift` directory. - -.Procedure - -* Get the ID of a stopped cluster by retrieving it from the `cluster-id` file by entering the following command: -+ -[source,terminal] ----- -$ sudo cat /var/lib/microshift/cluster-id ----- -.Example output -+ -[source,terminal] ----- -7cf13853-68f4-454e-8f5c-1af748cbfb1a ----- \ No newline at end of file diff --git a/modules/microshift-get-nonrunning-node-id-kubesystem.adoc b/modules/microshift-get-nonrunning-node-id-kubesystem.adoc new file mode 100644 index 000000000000..9bf45a81cfc2 --- /dev/null +++ b/modules/microshift-get-nonrunning-node-id-kubesystem.adoc @@ -0,0 +1,24 @@ +// Module included in the following assemblies: +// +// microshift_support/microshift-getting-node-id.adoc + +:_mod-docs-content-type: PROCEDURE +[id="microshift-get-nonrunning-node-id-kubesystem_{context}"] += Getting the node ID of a stopped node + +For a node that ran before, but is not running now, you can get the node ID from the `cluster-id` file in the `/var/lib/microshift` directory. + +.Procedure + +* Get the ID of a stopped node by retrieving it from the `cluster-id` file by entering the following command: ++ +[source,terminal] +---- +$ sudo cat /var/lib/microshift/cluster-id +---- +.Example output ++ +[source,terminal] +---- +7cf13853-68f4-454e-8f5c-1af748cbfb1a +---- \ No newline at end of file diff --git a/modules/microshift-http-proxy.adoc b/modules/microshift-http-proxy.adoc index 63d79ed1d924..6a9edfeb7f38 100644 --- a/modules/microshift-http-proxy.adoc +++ b/modules/microshift-http-proxy.adoc @@ -6,7 +6,7 @@ [id="microshift-http-proxy_{context}"] = Deploying {microshift-short} behind an HTTP or HTTPS proxy -Deploy a {microshift-short} cluster behind an HTTP or HTTPS proxy when you want to add basic anonymity and security measures to your pods. +Deploy a {microshift-short} node behind an HTTP or HTTPS proxy when you want to add basic anonymity and security measures to your pods. You must configure the host operating system to use the proxy service with all components initiating HTTP or HTTPS requests when deploying {microshift-short} behind a proxy. diff --git a/modules/microshift-info-collected-telemetry.adoc b/modules/microshift-info-collected-telemetry.adoc index 7f8d5d339326..c7dcfd15f57c 100644 --- a/modules/microshift-info-collected-telemetry.adoc +++ b/modules/microshift-info-collected-telemetry.adoc @@ -1,28 +1,28 @@ // Module included in the following assemblies: // -// * microshift_support/microshift-remote-cluster-monitoring.adoc +// * microshift_support/microshift-remote-node-monitoring.adoc :_mod-docs-content-type: REFERENCE [id="microshift-info-collected-by-telemetry_{context}"] = Information collected by the {microshift-short} Telemetry API -All metrics combined are generally under 2KB and not expected to consume cluster resources. +All metrics combined are generally under 2KB and not expected to consume node resources. The following information is collected by Telemetry: [id="microshift-telemetry-system-information_{context}"] == System information -The system information describes the basic configuration of your {microshift-short} cluster and where it is running, for example: +The system information describes the basic configuration of your {microshift-short} node and where it is running, for example: -* Version information, including the {microshift-short} cluster version. +* Version information, including the {microshift-short} node version. * The {op-system-base-full} version. * The {op-system-base} deployment type. [id="microshift-telemetry-sizing-information_{context}"] == Sizing information -Sizing information details the cluster capacity, for example: +Sizing information details the node capacity, for example: * The CPU cores {microshift-short} can use. * Architecture information. @@ -31,7 +31,7 @@ Sizing information details the cluster capacity, for example: [id="microshift-telemetry-usage-information_{context}"] == Usage information -Usage information outlines what is happening in the cluster, for example: +Usage information outlines what is happening in the node, for example: * The CPU usage in percentage. * The memory usage in percentage. diff --git a/modules/microshift-install-multus-running-cluster.adoc b/modules/microshift-install-multus-running-node.adoc similarity index 82% rename from modules/microshift-install-multus-running-cluster.adoc rename to modules/microshift-install-multus-running-node.adoc index edb5ade741b8..09554186c05a 100644 --- a/modules/microshift-install-multus-running-cluster.adoc +++ b/modules/microshift-install-multus-running-node.adoc @@ -3,10 +3,10 @@ // * microshift_networking/microshift-cni-multus.adoc :_mod-docs-content-type: CONCEPT -[id="microshift-multus-installing-on-running-cluster_{context}"] -= Installing the Multus CNI plugin on a running cluster +[id="microshift-multus-installing-on-running-node_{context}"] += Installing the Multus CNI plugin on a running node -If you want to attach additional networks to a pod for high-performance network configurations, you can install the {microshift-short} Multus RPM package. After installation, a host restart is required to recreate all the pods with the Multus annotation. +If you want to attach additional networks to a pod for high-performance network configurations, you can install the {microshift-short} Multus RPM package. After installation, a host restart is required to re-create all the pods with the Multus annotation. [IMPORTANT] ==== @@ -31,7 +31,7 @@ $ sudo dnf install microshift-multus If you create your custom resources (CRs) for additional networks now, you can complete your installation and apply configurations with one restart. ==== -. To apply the package manifest to an active cluster, restart the host by running the following command: +. To apply the package manifest to an active node, restart the host by running the following command: + [source,terminal] ---- diff --git a/modules/microshift-install-rhde-steps.adoc b/modules/microshift-install-rhde-steps.adoc index ed34e370fbd2..2563f98f37d5 100644 --- a/modules/microshift-install-rhde-steps.adoc +++ b/modules/microshift-install-rhde-steps.adoc @@ -16,13 +16,13 @@ For most installation types, you must also take the following steps: ** link:https://docs.redhat.com/en/documentation/red_hat_build_of_microshift/{ocp-version}/html/configuring/using-the-microshift-configuration-file[Using the {microshift-short} configuration file] -* Decide whether you need to configure storage for the application and tasks you are using in your {microshift-short} cluster, or disable the {microshift-short} storage plug-in completely. +* Decide whether you need to configure storage for the application and tasks you are using in your {microshift-short} node, or disable the {microshift-short} storage plugin completely. * For more information about creating volume groups and persistent volumes on {op-system-base}, see the following link: ** link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_logical_volumes/overview-of-logical-volume-management_configuring-and-managing-logical-volumes[Overview of logical volume management] -* Configure networking settings according to the access needs you plan for your {microshift-short} cluster and applications. Consider whether you want to use single or dual-stack networks, configure a firewall, or configure routes. +* Configure networking settings according to the access needs you plan for your {microshift-short} node and applications. Consider whether you want to use single or dual-stack networks, configure a firewall, or configure routes. + [NOTE] ==== diff --git a/modules/microshift-install-rhel-types.adoc b/modules/microshift-install-rhel-types.adoc index f63ce5a95ba7..73553de2cb7e 100644 --- a/modules/microshift-install-rhel-types.adoc +++ b/modules/microshift-install-rhel-types.adoc @@ -6,10 +6,10 @@ [id="microshift-install-rhel-types_{context}"] = {op-system-base} installation types -Choose the best {op-system-base-full} installation type based on where you want to run your cluster and what your applications need to do. For the best results, apply the following principles: +Choose the best {op-system-base-full} installation type based on where you want to run your node and what your applications need to do. For the best results, apply the following principles: * For every installation target, you must configure both the operating system and {microshift-short}. -* Consider your application storage needs, networking for cluster or application access, and your authentication and security requirements. +* Consider your application storage needs, networking for node or application access, and your authentication and security requirements. * Understand the differences between the {op-system-base} installation types, including the support scope of each, and the tools used. [id="microshift-get-ready-install-rpm_{context}"] diff --git a/modules/microshift-install-rpm-before.adoc b/modules/microshift-install-rpm-before.adoc index a21ab5dc2f38..29f9a3f86113 100644 --- a/modules/microshift-install-rpm-before.adoc +++ b/modules/microshift-install-rpm-before.adoc @@ -6,7 +6,7 @@ [id="microshift-install-rpm-before_{context}"] = Before installing {microshift-short} from an RPM package -Preparation of the host machine is recommended prior to installing {microshift-short} for memory configuration and FIPS mode. +Preparation of the host machine is recommended before installing {microshift-short} for memory configuration and FIPS mode. [id="microshift-configuring-volume-groups_{context}"] == Configuring volume groups @@ -22,5 +22,5 @@ If your use case requires running {microshift-short} containers in FIPS mode, yo [IMPORTANT] ==== -Because FIPS must be enabled before the operating system that your cluster uses starts for the first time, you cannot enable FIPS after you deploy a cluster. +Because FIPS must be enabled before the operating system that your node uses starts for the first time, you cannot enable FIPS after you deploy a node. ==== \ No newline at end of file diff --git a/modules/microshift-install-rpms-olm.adoc b/modules/microshift-install-rpms-olm.adoc index 9986155299f1..a2151c54b6d8 100644 --- a/modules/microshift-install-rpms-olm.adoc +++ b/modules/microshift-install-rpms-olm.adoc @@ -6,7 +6,7 @@ [id="microshift-installing-with-olm-from-rpm-package_{context}"] = Installing the Operator Lifecycle Manager (OLM) from an RPM package -When you install {microshift-short}, the Operator Lifecycle Manager (OLM) package is not installed by default. You can install the OLM on your {microshift-short} instance using an RPM package. +When you install {microshift-short}, the Operator Lifecycle Manager (OLM) package is not installed by default. You can install the OLM on your {microshift-short} instance by using an RPM package. .Procedure @@ -17,7 +17,7 @@ When you install {microshift-short}, the Operator Lifecycle Manager (OLM) packag $ sudo dnf install microshift-olm ---- -. To apply the manifest from the package to an active cluster, run the following command: +. To apply the manifest from the package to an active node, run the following command: + [source,terminal] ---- diff --git a/modules/microshift-kubeconfig-generating-additional-files.adoc b/modules/microshift-kubeconfig-generating-additional-files.adoc index af9f512aff58..a29d5983a1ea 100644 --- a/modules/microshift-kubeconfig-generating-additional-files.adoc +++ b/modules/microshift-kubeconfig-generating-additional-files.adoc @@ -71,7 +71,7 @@ $ sudo systemctl restart microshift $ cat /var/lib/microshift/resources/kubeadmin/alt-name-1/kubeconfig ---- -. Choose the `kubeconfig` file to use that contains the SAN or IP address you want to use to connect your cluster. In this example, the `kubeconfig` containing`alt-name-1` in the `cluster.server` field is the correct file. +. Choose the `kubeconfig` file to use that contains the SAN or IP address you want to use to connect your node. In this example, the `kubeconfig` containing`alt-name-1` in the `cluster.server` field is the correct file. + .Example contents of an additional `kubeconfig` file [source,yaml] diff --git a/modules/microshift-kubeconfig-local-access.adoc b/modules/microshift-kubeconfig-local-access.adoc index c60cfa37538c..949f25b4edfa 100644 --- a/modules/microshift-kubeconfig-local-access.adoc +++ b/modules/microshift-kubeconfig-local-access.adoc @@ -6,7 +6,7 @@ [id="microshift-kubeconfig-local-access_{context}"] = Local access kubeconfig file -The local access `kubeconfig` file is written to `/var/lib/microshift/resources/kubeadmin/kubeconfig`. This `kubeconfig` file provides access to the API server by using `localhost`. Choose this file when you are connecting the cluster locally. +The local access `kubeconfig` file is written to `/var/lib/microshift/resources/kubeadmin/kubeconfig`. This `kubeconfig` file provides access to the API server by using `localhost`. Choose this file when you are connecting the node locally. .Example contents of `kubeconfig` for local access [source,yaml] diff --git a/modules/microshift-kubeconfig-overview.adoc b/modules/microshift-kubeconfig-overview.adoc index 2d4112ed4d2f..d321baa9c68f 100644 --- a/modules/microshift-kubeconfig-overview.adoc +++ b/modules/microshift-kubeconfig-overview.adoc @@ -4,7 +4,7 @@ :_mod-docs-content-type: CONCEPT [id="kubeconfig-files-overview_{context}"] -= Kubeconfig files for configuring cluster access += Kubeconfig files for configuring node access The two categories of `kubeconfig` files used in {microshift-short} are local access and remote access. Every time {microshift-short} starts, a set of `kubeconfig` files for local and remote access to the API server are generated. These files are generated in the `/var/lib/microshift/resources/kubeadmin/` directory by using preexisting configuration information. diff --git a/modules/microshift-low-latency-concept.adoc b/modules/microshift-low-latency-concept.adoc index d817fdf65e6f..39413de101ef 100644 --- a/modules/microshift-low-latency-concept.adoc +++ b/modules/microshift-low-latency-concept.adoc @@ -6,7 +6,7 @@ [id="microshift-low-latency-concept_{context}"] = Lowering latency in {microshift-short} applications -Latency is defined as the time from an event to the response to that event. You can use low latency configurations and tuning in a {microshift-short} cluster running in an operational or software-defined control system where an edge device has to respond quickly to an external event. You can fully optimize low latency performance by combining {microshift-short} configurations with operating system tuning and workload partitioning. +Latency is defined as the time from an event to the response to that event. You can use low latency configurations and tuning in a {microshift-short} node running in an operational or software-defined control system where an edge device has to respond quickly to an external event. You can fully optimize low latency performance by combining {microshift-short} configurations with operating system tuning and workload partitioning. [IMPORTANT] ==== @@ -15,7 +15,7 @@ The CPU set for management applications, such as the {microshift-short} service, [id="microshift-low-latency-workflow_{context}"] == Workflow for configuring low latency for {microshift-short} applications -To configure low latency for applications running in a {microshift-short} cluster, you must complete the following tasks: +To configure low latency for applications running in a {microshift-short} node, you must complete the following tasks: Required:: * Install the `microshift-low-latency` RPM. diff --git a/modules/microshift-low-latency-config-yaml.adoc b/modules/microshift-low-latency-config-yaml.adoc index 657ba9ebb42f..90e5c9b62ee4 100644 --- a/modules/microshift-low-latency-config-yaml.adoc +++ b/modules/microshift-low-latency-config-yaml.adoc @@ -6,12 +6,12 @@ [id="microshift-low-latency-config-yaml_{context}"] = Configuration kubelet parameters and values in {microshift-short} -The first step in enabling low latency to a {microshift-short} cluster is to add configurations to the {microshift-short} `config.yaml` file. +The first step in enabling low latency to a {microshift-short} node is to add configurations to the {microshift-short} `config.yaml` file. .Prerequisites -* You installed the OpenShift CLI (`oc`). -* You have root access to the cluster. +* You installed the {oc-first}. +* You have root access to the node. * You made a copy of the provided `config.yaml.default` file in the `/etc/microshift/` directory, and renamed it `config.yaml`. .Procedure diff --git a/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc b/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc index 64ed2ba54adc..a6b79a4c5d36 100644 --- a/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc +++ b/modules/microshift-low-latency-install-kernelrt-rhel-edge.adoc @@ -6,7 +6,7 @@ [id="microshift-low-latency-install-kernelrt-rhel-edge_{context}"] = Installing the {op-system-rt-kernel} in a {op-system-ostree-first} image -You can include the real-time kernel in a {op-system-ostree} image deployment using image builder. The following example blueprint sections include references gathered from the previous steps required to configure low latency for a {microshift-short} cluster. +You can include the real-time kernel in a {op-system-ostree} image deployment using image builder. The following example blueprint sections include references gathered from the previous steps required to configure low latency for a {microshift-short} node. .Prerequisites * You have a Red Hat subscription enabled on the host that includes {op-system-rt-kernel}. diff --git a/modules/microshift-low-latency-install-kernelrt-rpm.adoc b/modules/microshift-low-latency-install-kernelrt-rpm.adoc index 7cd45253a48a..cee5c3996f6e 100644 --- a/modules/microshift-low-latency-install-kernelrt-rpm.adoc +++ b/modules/microshift-low-latency-install-kernelrt-rpm.adoc @@ -6,7 +6,7 @@ [id="microshift-low-latency-install-kernelrt_{context}"] = Installing the {op-system-rt-kernel} -Although the real-time kernel is not necessary for low latency workloads, using the {op-system-rtk} can optimize low latency performance. You can install it on a host using RPM packages, and include it in a {op-system-ostree-first} image deployment. +Although the real-time kernel is not necessary for low latency workloads, using the {op-system-rtk} can optimize low latency performance. You can install it on a host by using RPM packages, and include it in a {op-system-ostree-first} image deployment. .Prerequisites diff --git a/modules/microshift-low-latency-prepare-workload.adoc b/modules/microshift-low-latency-prepare-workload.adoc index bf7996ae8279..a4b6e00696db 100644 --- a/modules/microshift-low-latency-prepare-workload.adoc +++ b/modules/microshift-low-latency-prepare-workload.adoc @@ -80,11 +80,11 @@ spec: <3> Disables the CPU completely fair scheduler (CFS) quota at the pod run time. <4> Enables or disables C-states for each CPU. Set the value to `disable` to provide the best performance for a high-priority pod. <5> Sets the `cpufreq` governor for each CPU. The `performance` governor is recommended for high-priority workloads. -<6> The `runtimeClassName` must match the name of the performance profile configured in the cluster. For example, `microshift-low-latency`. +<6> The `runtimeClassName` must match the name of the performance profile configured in the node. For example, `microshift-low-latency`. + [NOTE] ==== -Disable CPU load balancing only when the CPU manager static policy is enabled and for pods with guaranteed QoS that use whole CPUs. Otherwise, disabling CPU load balancing can affect the performance of other containers in the cluster. +Disable CPU load balancing only when the CPU manager static policy is enabled and for pods with guaranteed QoS that use whole CPUs. Otherwise, disabling CPU load balancing can affect the performance of other containers in the node. ==== + [IMPORTANT] diff --git a/modules/microshift-low-latency-tuned-conc.adoc b/modules/microshift-low-latency-tuned-conc.adoc index 920fd1fbdbcf..e2539a312e24 100644 --- a/modules/microshift-low-latency-tuned-conc.adoc +++ b/modules/microshift-low-latency-tuned-conc.adoc @@ -8,7 +8,7 @@ As a {op-system-base-full} system administrator, you can use the TuneD service to optimize the performance profile of {op-system-base} for a variety of use cases. TuneD monitors and optimizes system performance under certain workloads, including latency performance. -* Use TuneD profiles to tune your system for different use cases, such as deploying a low-latency {microshift-short} cluster. +* Use TuneD profiles to tune your system for different use cases, such as deploying a low-latency {microshift-short} node. * You can modify the rules defined for each profile and customize tuning for a specific device. * When you switch to another profile or deactivate TuneD, all changes made to the system settings by the previous profile revert back to their original state. * You can also configure TuneD to react to changes in device usage and adjusts settings to improve performance of active devices and reduce power consumption of inactive devices. \ No newline at end of file diff --git a/modules/microshift-low-latency-tuned-profile.adoc b/modules/microshift-low-latency-tuned-profile.adoc index b883350b35ab..cef171e774d5 100644 --- a/modules/microshift-low-latency-tuned-profile.adoc +++ b/modules/microshift-low-latency-tuned-profile.adoc @@ -6,11 +6,11 @@ [id="microshift-low-latency-tuned-profile_{context}"] = Configuring the {microshift-short} TuneD profile -Configure a TuneD profile for your host to use low latency with {microshift-short} workloads using the `microshift-baseline-variables.conf` configuration file provided in the {op-system-base-full} `/etc/tuned/` host directory after you install the `microshift-low-latency` RPM package. +Configure a TuneD profile for your host to use low latency with {microshift-short} workloads by using the `microshift-baseline-variables.conf` configuration file provided in the {op-system-base-full} `/etc/tuned/` host directory after you install the `microshift-low-latency` RPM package. .Prerequisites -* You have root access to the cluster. +* You have root access to the node. * You installed the `microshift-low-latency` RPM package. * Your {op-system-base} host has TuneD installed. See link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/getting-started-with-tuned_monitoring-and-managing-system-status-and-performance#the-location-of-tuned-profiles_getting-started-with-tuned[Getting started with TuneD] (RHEL documentation). diff --git a/modules/microshift-lvm-thin-volumes.adoc b/modules/microshift-lvm-thin-volumes.adoc index 06a1bab1246f..714f2937be9c 100644 --- a/modules/microshift-lvm-thin-volumes.adoc +++ b/modules/microshift-lvm-thin-volumes.adoc @@ -8,7 +8,7 @@ To use advanced storage features such as creating volume snapshots or volume cloning, you must perform the following actions: -* Configure both the logical volume manager storage (LVMS) provider and the cluster. +* Configure both the logical volume manager storage (LVMS) provider and the node. * Provision a logical volume manager (LVM) thin-pool on the {op-system-ostree} host. * Attach LVM thin-pools to a volume group. @@ -24,7 +24,7 @@ When using thin provisioning, it is important that you monitor the storage pool For LVMS to manage thin logical volumes (LVs), a thin-pool `device-class` array must be specified in the `etc/lvmd.yaml` configuration file. Multiple thin-pool device classes are permitted. -If additional storage pools are configured with device classes, then additional storage classes must also exist to expose the storage pools to users and workloads. To enable dynamic provisioning on a thin-pool, a `StorageClass` resource must be present on the cluster. The `StorageClass` resource specifies the source `device-class` array in the `topolvm.io/device-class` parameter. +If additional storage pools are configured with device classes, then additional storage classes must also exist to expose the storage pools to users and workloads. To enable dynamic provisioning on a thin-pool, a `StorageClass` resource must be present on the node. The `StorageClass` resource specifies the source `device-class` array in the `topolvm.io/device-class` parameter. .Example `lvmd.yaml` file that specifies a single device class for a thin-pool [source, yaml] diff --git a/modules/microshift-lvms-deployment.adoc b/modules/microshift-lvms-deployment.adoc index 0c00a1b5c78a..d1cf5a57252f 100644 --- a/modules/microshift-lvms-deployment.adoc +++ b/modules/microshift-lvms-deployment.adoc @@ -6,6 +6,6 @@ [id="microshift-lvms-deployment_{context}"] = LVMS deployment -LVMS is automatically deployed on to the cluster in the `openshift-storage` namespace after {microshift-short} starts. +LVMS is automatically deployed on to the node in the `openshift-storage` namespace after {microshift-short} starts. LVMS uses `StorageCapacity` tracking to ensure that pods with an LVMS PVC are not scheduled if the requested storage is greater than the free storage of the volume group. For more information about `StorageCapacity` tracking, read link:https://kubernetes.io/docs/concepts/storage/storage-capacity/[Storage Capacity]. \ No newline at end of file diff --git a/modules/microshift-manifests-overview.adoc b/modules/microshift-manifests-overview.adoc index 7ea36049d243..f8407b0ccc68 100644 --- a/modules/microshift-manifests-overview.adoc +++ b/modules/microshift-manifests-overview.adoc @@ -6,16 +6,16 @@ [id="microshift-manifests-overview_{context}"] = How Kustomize works with manifests to deploy applications -The `kustomize` configuration management tool is integrated with {microshift-short}. You can use Kustomize and the {oc-first} together to apply customizations to your application manifests and deploy those applications to a {microshift-short} cluster. +The `kustomize` configuration management tool is integrated with {microshift-short}. You can use Kustomize and the {oc-first} together to apply customizations to your application manifests and deploy those applications to a {microshift-short} node. * A `kustomization.yaml` file is a specification of resources plus customizations. * Kustomize uses a `kustomization.yaml` file to load a resource, such as an application, then applies any changes you want to that application manifest and produces a copy of the manifest with the changes overlaid. * Using a manifest copy with an overlay keeps the original configuration file for your application intact, while enabling you to deploy iterations and customizations of your applications efficiently. -* You can then deploy the application in your {microshift-short} cluster with an `oc` command. +* You can then deploy the application in your {microshift-short} node with an `oc` command. [NOTE] ==== -At each system start, {microshift-short} deletes the manifests found in the `delete` subdirectories and then applies the manifest files found in the manifest directories to the cluster. +At each system start, {microshift-short} deletes the manifests found in the `delete` subdirectories and then applies the manifest files found in the manifest directories to the node. ==== [id="how-microshift-uses-manifests"] @@ -27,7 +27,7 @@ At every start, {microshift-short} searches the following manifest directories f * `/usr/lib/microshift/` * `/usr/lib/microshift/manifests.d/++*++` -{microshift-short} automatically runs the equivalent of the `kubectl apply -k` command to apply the manifests to the cluster if any of the following file types exists in the searched directories: +{microshift-short} automatically runs the equivalent of the `kubectl apply -k` command to apply the manifests to the node if any of the following file types exists in the searched directories: * `kustomization.yaml` * `kustomization.yml` diff --git a/modules/microshift-multus-intro.adoc b/modules/microshift-multus-intro.adoc index 52657a1f6940..82ef77d3054b 100644 --- a/modules/microshift-multus-intro.adoc +++ b/modules/microshift-multus-intro.adoc @@ -6,7 +6,7 @@ [id="microshift-multus-intro_{context}"] = Secondary networks in {microshift-short} -During cluster installation, the _default_ pod network is configured with default values unless you customize the configuration. The default network handles all ordinary network traffic for the cluster. Using the {microshift-short} Multus CNI plugin, you can add additional interfaces to pods from other networks. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing. +During node installation, the _default_ pod network is configured with default values unless you customize the configuration. The default network handles all ordinary network traffic for the node. Using the {microshift-short} Multus CNI plugin, you can add additional interfaces to pods from other networks. This gives you flexibility when you configure pods that deliver network functionality, such as switching or routing. [id="microshift-supported-additional-networks_{context}"] == Supported secondary networks for network isolation @@ -43,7 +43,7 @@ The Multus CNI plugin is deployed when the {microshift-short} service starts up. [id="microshift-additional-network-how-implemented_{context}"] == How secondary networks are implemented -All of the pods in the cluster still use the cluster-wide default network to maintain connectivity across the cluster. Every pod has an `eth0` interface that is attached to the cluster-wide pod network. +All of the pods in the node still use the node-wide default network to maintain connectivity across the node. Every pod has an `eth0` interface that is attached to the node-wide pod network. * You can view the interfaces for a pod by using the `oc get pod -o=jsonpath='{ .metadata.annotations.k8s\.v1\.cni\.cncf\.io/network-status }'` command. * If you add secondary network interfaces that use the {microshift-short} Multus CNI, they are named `net1`, `net2`, ..., `netN`. diff --git a/modules/microshift-nw-advertise-address.adoc b/modules/microshift-nw-advertise-address.adoc index f0e175a5b85d..0beb4b1221cb 100644 --- a/modules/microshift-nw-advertise-address.adoc +++ b/modules/microshift-nw-advertise-address.adoc @@ -6,11 +6,11 @@ [id="microshift-yaml-advertiseAddress_{context}"] = Configuring the advertise address network flag -The `apiserver.advertiseAddress` flag specifies the IP address on which to advertise the API server to members of the cluster. This address must be reachable by the cluster. You can set a custom IP address here, but you must also add the IP address to a host interface. Customizing this parameter preempts {microshift-short} from adding a default IP address to the `br-ex` network interface. +The `apiserver.advertiseAddress` flag specifies the IP address on which to advertise the API server to members of the node. This address must be reachable by the node. You can set a custom IP address here, but you must also add the IP address to a host interface. Customizing this parameter preempts {microshift-short} from adding a default IP address to the `br-ex` network interface. [IMPORTANT] ==== -If you customize the `advertiseAddress` IP address, make sure it is reachable by the cluster when {microshift-short} starts by adding the IP address to a host interface. +If you customize the `advertiseAddress` IP address, make sure it is reachable by the node when {microshift-short} starts by adding the IP address to a host interface. ==== If unset, the default value is set to the next immediate subnet after the service network. For example, when the service network is `10.43.0.0/16`, the `advertiseAddress` is set to `10.44.0.0/32`. diff --git a/modules/microshift-nw-create-http-based-route.adoc b/modules/microshift-nw-create-http-based-route.adoc index 30f7cf67e27d..784bc26852bd 100644 --- a/modules/microshift-nw-create-http-based-route.adoc +++ b/modules/microshift-nw-create-http-based-route.adoc @@ -11,8 +11,9 @@ A route allows you to host your application at a public URL. It can either be se The following procedure describes how to create a simple HTTP-based route to a web application, using the `hello-microshift` application as an example. .Prerequisites -* You installed the OpenShift CLI (`oc`). -* You have access to your {microshift-short} cluster. + +* You installed the {oc-first}. +* You have access to your {microshift-short} node. * You have a web application that exposes a port and a TCP endpoint listening for traffic on the port. .Procedure diff --git a/modules/microshift-nw-enforcing-hsts-per-domain.adoc b/modules/microshift-nw-enforcing-hsts-per-domain.adoc index 4296bfe0b484..0e7a32bf942b 100644 --- a/modules/microshift-nw-enforcing-hsts-per-domain.adoc +++ b/modules/microshift-nw-enforcing-hsts-per-domain.adoc @@ -6,7 +6,7 @@ [id="microshift-nw-enforcing-hsts-per-domain_{context}"] = Enforcing HTTP Strict Transport Security per-domain -You can configure a route with a compliant HSTS policy annotation. To handle upgraded clusters with non-compliant HSTS routes, you can update the manifests at the source and apply the updates. +You can configure a route with a compliant HSTS policy annotation. To handle an upgraded node with noncompliant HSTS routes, you can update the manifests at the source and apply the updates. You cannot use `oc expose route` or `oc create route` commands to add a route in a domain that enforces HSTS because the API for these commands does not accept annotations. @@ -16,12 +16,12 @@ HSTS cannot be applied to insecure, or non-TLS, routes. ==== .Prerequisites -* You have root access to the cluster. +* You have root access to the node. * You installed the {oc-first}. .Procedure -* Apply HSTS to all routes in the cluster by running the following `oc annotate command`: +* Apply HSTS to all routes in the node by running the following `oc annotate command`: + [source,terminal] ---- diff --git a/modules/microshift-nw-ipv6-concept.adoc b/modules/microshift-nw-ipv6-concept.adoc index e9e731b77259..25cdf14b3f2b 100644 --- a/modules/microshift-nw-ipv6-concept.adoc +++ b/modules/microshift-nw-ipv6-concept.adoc @@ -6,16 +6,16 @@ [id="microshift-intro-ipv6_{context}"] = IPv6 networking with {microshift-short} -The {microshift-short} service defaults to IPv4 address families cluster-wide. However, IPv6 single-stack and IPv4/IPv6 dual-stack networking is available on supported platforms. +The {microshift-short} service defaults to IPv4 address families node-wide. However, IPv6 single-stack and IPv4/IPv6 dual-stack networking is available on supported platforms. * When you set the values for IPv6 in the {microshift-short} configuration file and restart the service, settings managed by the OVN-Kubernetes network plugin are updated automatically. * After migrating to dual-stack networking, both new and existing pods have dual-stack networking enabled. -* If you require cluster-wide IPv6 access, such as for the control plane and other services, use the following configuration examples. The {microshift-short} Multus Container Network Interface (CNI) plugin can enable IPv6 for pods. -* For dual-stack networking, each {microshift-short} cluster network and service network supports up to two values in the cluster and service network configuration parameters. +* If you require node-wide IPv6 access, such as for the control plane and other services, use the following configuration examples. The {microshift-short} Multus Container Network Interface (CNI) plugin can enable IPv6 for pods. +* For dual-stack networking, each {microshift-short} node network and service network supports up to two values in the node and service network configuration parameters. [IMPORTANT] ==== -Plan for IPv6 before starting {microshift-short} for the first time. Switching a cluster to and from different IP families is not supported unless you are migrating a cluster from default single-stack to dual-stack networking. +Plan for IPv6 before starting {microshift-short} for the first time. Switching a node to and from different IP families is not supported unless you are migrating a node from default single-stack to dual-stack networking. If you configure your networking for either IPv6 single stack or IPv4/IPv6 dual stack, you must restart application pods and services. Otherwise pods and services remain configured with the default IP family. ==== diff --git a/modules/microshift-nw-ipv6-dual-stack-config.adoc b/modules/microshift-nw-ipv6-dual-stack-config.adoc index 250fe86c33c7..85d30af09f28 100644 --- a/modules/microshift-nw-ipv6-dual-stack-config.adoc +++ b/modules/microshift-nw-ipv6-dual-stack-config.adoc @@ -6,10 +6,10 @@ [id="microshift-configuring-ipv6-dual-stack-config_{context}"] = Configuring IPv6 dual-stack networking before {microshift-short} starts -You can configure your {microshift-short} cluster to run on dual-stack networking that supports IPv4 and IPv6 address families by using the configuration file before starting the service. +You can configure your {microshift-short} node to run on dual-stack networking that supports IPv4 and IPv6 address families by using the configuration file before starting the service. -* The first IP family in the configuration is the primary IP stack in the cluster. -* After the cluster is running with dual-stack networking, enable application pods and add-on services for dual-stack by restarting them. +* The first IP family in the configuration is the primary IP stack in the node. +* After the node is running with dual-stack networking, enable application pods and add-on services for dual-stack by restarting them. [IMPORTANT] ==== @@ -23,9 +23,9 @@ When using dual-stack networking where IPv6 is required, you cannot use IPv4-map .Prerequisites -* You installed the OpenShift CLI (`oc`). -* You have root access to the cluster. -* Your cluster uses the OVN-Kubernetes network plugin. +* You installed the {oc-first}. +* You have root access to the node. +* Your node uses the OVN-Kubernetes network plugin. * The host has both IPv4 and IPv6 addresses and routes, including a default for each. * The host has at least two L3 networks, IPv4 and IPv6. diff --git a/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc b/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc index 4fbfc4a22b4e..40459d85208d 100644 --- a/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc +++ b/modules/microshift-nw-ipv6-dual-stack-migrating-config.adoc @@ -4,13 +4,13 @@ :_mod-docs-content-type: PROCEDURE [id="microshift-nw-ipv6-dual-stack-migrating-config_{context}"] -= Migrating a {microshift-short} cluster to IPv6 dual-stack networking += Migrating a {microshift-short} node to IPv6 dual-stack networking -You can convert a single-stack cluster to dual-stack cluster networking that supports IPv4 and IPv6 address families by setting two entries in the service and cluster network parameters in the {microshift-short} configuration file. +You can convert a single-stack node to dual-stack node networking that supports IPv4 and IPv6 address families by setting two entries in the service and node network parameters in the {microshift-short} configuration file. -* The first IP family in the configuration is the primary IP stack in the cluster. +* The first IP family in the configuration is the primary IP stack in the node. * {microshift-short} system pods and services are automatically updated upon {microshift-short} restart. -* After the cluster is migrated to dual-stack networking and has restarted, enable workload pods and services for dual-stack networking by restarting them. +* After the node is migrated to dual-stack networking and has restarted, enable workload pods and services for dual-stack networking by restarting them. [IMPORTANT] ==== @@ -24,9 +24,9 @@ When using dual-stack networking where IPv6 is required, you cannot use IPv4-map .Prerequisites -* You installed the OpenShift CLI (`oc`). -* You have root access to the cluster. -* Your cluster uses the OVN-Kubernetes network plugin. +* You installed the {oc-first}. +* You have root access to the node. +* Your node uses the OVN-Kubernetes network plugin. * The host has both IPv4 and IPv6 addresses and routes, including a default for each. * The host has at least two L3 networks, IPv4 and IPv6. @@ -141,8 +141,8 @@ $ oc get pod -n openshift-ingress router-default-5b75594b4-228z7 -o jsonpath='{. ---- [{"ip":"10.42.0.3"},{"ip":"fd01:0:0:1::3"}] ---- - ++ [NOTE] ==== To return to single-stack networking, you can remove the second entry to the networks and return to the single stack that was configured before migrating to dual-stack. -==== \ No newline at end of file +==== diff --git a/modules/microshift-nw-ipv6-single-stack-config.adoc b/modules/microshift-nw-ipv6-single-stack-config.adoc index 80bb3b12a06d..5099135d4548 100644 --- a/modules/microshift-nw-ipv6-single-stack-config.adoc +++ b/modules/microshift-nw-ipv6-single-stack-config.adoc @@ -10,9 +10,9 @@ You can use the IPv6 network protocol by updating the {microshift-short} service .Prerequisites -* You installed the OpenShift CLI (`oc`). -* You have root access to the cluster. -* Your cluster uses the OVN-Kubernetes network plugin. +* You installed the {oc-first}. +* You have root access to the node. +* Your node uses the OVN-Kubernetes network plugin. * The host has an IPv6 address and IPv6 routes, including the default. .Procedure diff --git a/modules/microshift-nw-multus-add-pod.adoc b/modules/microshift-nw-multus-add-pod.adoc index d2524f8f6652..1e9acf4a43ce 100644 --- a/modules/microshift-nw-multus-add-pod.adoc +++ b/modules/microshift-nw-multus-add-pod.adoc @@ -6,14 +6,14 @@ [id="microshift-nw-multus-add-pod_{context}"] = Adding a pod to an additional network -You can add a pod to an additional network. At the time a pod is created, additional networks are attached to it. The pod continues to send normal cluster-related network traffic over the default network. +You can add a pod to an additional network. At the time a pod is created, additional networks are attached to it. The pod continues to send normal node-related network traffic over the default network. If you want to attach additional networks to a pod that is already running, you must restart the pod. .Prerequisites * The {oc-first} is installed. -* The cluster is running. +* The node is running. * A network defined by a `NetworkAttachmentDefinition` object that you want to attach the pod to exists. .Procedure diff --git a/modules/microshift-nw-network-policy-intro.adoc b/modules/microshift-nw-network-policy-intro.adoc index fd014723c318..e2a812c191de 100644 --- a/modules/microshift-nw-network-policy-intro.adoc +++ b/modules/microshift-nw-network-policy-intro.adoc @@ -6,16 +6,13 @@ [id="microshift-nw-network-policy-intro_{context}"] = How network policy works in {microshift-short} -In a cluster using the default OVN-Kubernetes Container Network Interface (CNI) plugin for {microshift-short}, network isolation is controlled by both firewalld, which is configured on the host, and by `NetworkPolicy` objects created within {microshift-short}. Simultaneous use of firewalld and `NetworkPolicy` is supported. +In a node that is using the default OVN-Kubernetes Container Network Interface (CNI) plugin for {microshift-short}, network isolation is controlled by both firewalld, which is configured on the host, and by `NetworkPolicy` objects created within {microshift-short}. Simultaneous use of firewalld and `NetworkPolicy` is supported. * Network policies work only within boundaries of OVN-Kubernetes-controlled traffic, so they can apply to every situation except for `hostPort/hostNetwork` enabled pods. * Firewalld settings also do not apply to `hostPort/hostNetwork` enabled pods. -[NOTE] -==== -Firewalld rules run before any `NetworkPolicy` is enforced. -==== +* Firewalld rules run before any `NetworkPolicy` is enforced. [WARNING] ==== @@ -24,7 +21,7 @@ Network policy does not apply to the host network namespace. Pods with host netw Network policies cannot block traffic from localhost. ==== -By default, all pods in a {microshift-short} node are accessible from other pods and network endpoints. To isolate one or more pods in a cluster, you can create `NetworkPolicy` objects to indicate allowed incoming connections. You can create and delete `NetworkPolicy` objects. +By default, all pods in a {microshift-short} node are accessible from other pods and network endpoints. To isolate one or more pods in a node, you can create `NetworkPolicy` objects to indicate allowed incoming connections. You can create and delete `NetworkPolicy` objects. If a pod is matched by selectors in one or more `NetworkPolicy` objects, then the pod accepts only connections that are allowed by at least one of those `NetworkPolicy` objects. A pod that is not selected by any `NetworkPolicy` objects is fully accessible. diff --git a/modules/microshift-nw-topology.adoc b/modules/microshift-nw-topology.adoc index a2a684e90e11..b377234cd1cd 100644 --- a/modules/microshift-nw-topology.adoc +++ b/modules/microshift-nw-topology.adoc @@ -27,7 +27,7 @@ A virtual switch named ``. The OVN node switch is named according to OVN cluster router:: A virtual router named `ovn_cluster_router`, also known as the distributed router. -** In this example, the cluster network is `10.42.0.0/16`. +** In this example, the node network is `10.42.0.0/16`. OVN join switch:: A virtual switch named `join`. diff --git a/modules/microshift-oc-apis-errors.adoc b/modules/microshift-oc-apis-errors.adoc index ab6ac317ade2..6cfbc618a895 100644 --- a/modules/microshift-oc-apis-errors.adoc +++ b/modules/microshift-oc-apis-errors.adoc @@ -4,30 +4,34 @@ :_mod-docs-content-type: CONCEPT [id="microshift-oc-apis-errors_{context}"] -= oc command errors in {product-title} += oc command errors in {microshift-short} Not all {oc-first} commands are relevant for {microshift-short} deployments. When you use `oc` to make a request call against an unsupported API, the `oc` binary usually generates an error message about a resource that cannot be found. -.Example output - -For example, when the following `new-project` command is run: - +* For example, when you run the following `new-project` command: ++ [source,terminal] ---- $ oc new-project test ---- - ++ The following error message can be generated: - ++ [source,terminal] ---- Error from server (NotFound): the server could not find the requested resource (get projectrequests.project.openshift.io) ---- -And when the `get projects` command is run, another error can be generated as follows: - +* When you run the `get projects` command, another error can be generated as follows: ++ [source,terminal] ---- $ oc get projects +---- ++ +The following error message can be generated: ++ +[source,terminal] +---- error: the server doesn't have a resource type "projects" ----- \ No newline at end of file +---- diff --git a/modules/microshift-oc-mirror-about-con.adoc b/modules/microshift-oc-mirror-about-con.adoc index 72c325c0cfbf..1c4ea03b13ec 100644 --- a/modules/microshift-oc-mirror-about-con.adoc +++ b/modules/microshift-oc-mirror-about-con.adoc @@ -8,4 +8,4 @@ You can use the oc-mirror OpenShift CLI (oc) plugin with {microshift-short} to filter and delete images from Operator catalogs. You can then mirror the filtered catalog contents to a mirror registry or use the container images in disconnected or offline deployments. -The procedure to mirror content from Red Hat-hosted registries connected to the internet to a disconnected image registry is the same, independent of the registry you select. After you mirror the contents of your catalog, configure each cluster to retrieve this content from your mirror registry. +The procedure to mirror content from Red Hat-hosted registries connected to the internet to a disconnected image registry is the same, independent of the registry you select. After you mirror the contents of your catalog, configure each node to retrieve this content from your mirror registry. diff --git a/modules/microshift-oc-mirror-connectivity.adoc b/modules/microshift-oc-mirror-connectivity.adoc index 89b827d1f8f9..639115905b54 100644 --- a/modules/microshift-oc-mirror-connectivity.adoc +++ b/modules/microshift-oc-mirror-connectivity.adoc @@ -9,17 +9,17 @@ When you populate your registry, you can use one of following connectivity scenarios: Connected mirroring:: -If you have a host that can access both the internet and your mirror registry, but not your cluster node, you can directly mirror the content from that machine. +If you have a host that can access both the internet and your mirror registry, but not your node, you can directly mirror the content from that machine. Disconnected mirroring:: If you do not have a host that can access both the internet and your mirror registry, you must mirror the images to a file system and then bring that host or removable media into your disconnected environment. + [IMPORTANT] ==== -A container registry must be reachable by every machine in the cluster that you provision. Installing, updating, and other operations, such as relocating workloads, fail if the registry is unreachable. +A container registry must be reachable by every machine in the node that you provision. Installing, updating, and other operations, such as relocating workloads, fail if the registry is unreachable. ==== To avoid problems caused by an unreachable registry, use the following standard practices: * Run mirror registries in a highly available way. -* Ensure that the mirror registry at least matches the production availability of your clusters. +* Ensure that the mirror registry at least matches the production availability of your node. diff --git a/modules/microshift-oc-mirror-creating-imageset-config.adoc b/modules/microshift-oc-mirror-creating-imageset-config.adoc index aa84c2f4341b..fc25dc8a5b1e 100644 --- a/modules/microshift-oc-mirror-creating-imageset-config.adoc +++ b/modules/microshift-oc-mirror-creating-imageset-config.adoc @@ -56,4 +56,4 @@ The `platform` field, related fields, and Helm are not supported by {microshift- .Next steps * Use the oc-mirror plugin to mirror an image set directly to a target mirror registry. * Configure CRI-O. -* Apply the catalog sources to your clusters. +* Apply the catalog sources to your node. diff --git a/modules/microshift-oc-mirror-install-catalog-cluster.adoc b/modules/microshift-oc-mirror-install-catalog-node.adoc similarity index 91% rename from modules/microshift-oc-mirror-install-catalog-cluster.adoc rename to modules/microshift-oc-mirror-install-catalog-node.adoc index 7d00727d20a3..0c8fe9ec67f2 100644 --- a/modules/microshift-oc-mirror-install-catalog-cluster.adoc +++ b/modules/microshift-oc-mirror-install-catalog-node.adoc @@ -3,10 +3,10 @@ // * microshift_running_apps/microshift_operators/microshift-operators-oc-mirror.adoc :_mod-docs-content-type: PROCEDURE -[id="microshift-oc-mirror-install-catalog-in-cluster_{context}"] +[id="microshift-oc-mirror-install-catalog-in-node_{context}"] = Installing a custom catalog created with the oc-mirror plugin -After you mirror your image set to the mirror registry, you must apply the generated `CatalogSource` custom resource (CR) into the cluster. Operator Lifecycle Manager (OLM) uses the `CatalogSource` CR to retrieve information about the available Operators in the mirror registry. You must then create and apply a subscription CR to subscribe to your custom catalog. +After you mirror your image set to the mirror registry, you must apply the generated `CatalogSource` custom resource (CR) into the node. Operator Lifecycle Manager (OLM) uses the `CatalogSource` CR to retrieve information about the available Operators in the mirror registry. You must then create and apply a subscription CR to subscribe to your custom catalog. .Prerequisites diff --git a/modules/microshift-oc-mirror-to-mirror.adoc b/modules/microshift-oc-mirror-to-mirror.adoc index 050c74f8815e..7e03caa4d904 100644 --- a/modules/microshift-oc-mirror-to-mirror.adoc +++ b/modules/microshift-oc-mirror-to-mirror.adoc @@ -36,7 +36,7 @@ Rendering catalog image "registry.example.com/redhat/redhat-operator-index:v{ocp -- [IMPORTANT] ==== -You must use the `ImageDigestMirrorSet` YAML file as reference content for manual configuration of CRI-O in {microshift-short}. You cannot apply the resource directly into a {microshift-short} cluster. +You must use the `ImageDigestMirrorSet` YAML file as reference content for manual configuration of CRI-O in {microshift-short}. You cannot apply the resource directly into a {microshift-short} node. ==== -- diff --git a/modules/microshift-olm-deploy-op-disconnected-con.adoc b/modules/microshift-olm-deploy-op-disconnected-con.adoc index 78eaaaf73346..6fc8f063fe58 100644 --- a/modules/microshift-olm-deploy-op-disconnected-con.adoc +++ b/modules/microshift-olm-deploy-op-disconnected-con.adoc @@ -3,17 +3,17 @@ //* microshift_running_apps/microshift_operators/microshift-operators-olm.adoc :_mod-docs-content-type: CONCEPT -[id="microshift-adding-OLM-Operators-to-disconnected-cluster_{context}"] -= About adding OLM-based Operators to a disconnected cluster +[id="microshift-adding-OLM-Operators-to-disconnected-node_{context}"] += About adding OLM-based Operators to a disconnected node -For Operators that are installed on disconnected clusters, Operator Lifecycle Manager (OLM) by default cannot access sources hosted on remote registries because those remote sources require full internet connectivity. Therefore, you must mirror the remote registries to a highly available container registry. +For Operators that are installed on disconnected nodes, Operator Lifecycle Manager (OLM) by default cannot access sources hosted on remote registries because those remote sources require full internet connectivity. Therefore, you must mirror the remote registries to a highly available container registry. The following steps are required to use OLM-based Operators in disconnected situations: * Include OLM in the container image list for your mirror registry. * Configure the system to use your mirror registry by updating your CRI-O configuration directly. `ImageContentSourcePolicy` is not supported in {microshift-short}. -* Add a `CatalogSource` object to the cluster so that the OLM catalog Operator can use the local catalog on the mirror registry. +* Add a `CatalogSource` object to the node so that the OLM catalog Operator can use the local catalog on the mirror registry. * Ensure that {microshift-short} is installed to run in a disconnected capacity. * Ensure that the network settings are configured to run in disconnected mode. -After enabling OLM in a disconnected cluster, you can continue to use your internet-connected workstation to keep your local catalog sources updated as newer versions of Operators are released. +After enabling OLM in a disconnected node, you can continue to use your internet-connected workstation to keep your local catalog sources updated as newer versions of Operators are released. diff --git a/modules/microshift-olm-deploy-ops-con.adoc b/modules/microshift-olm-deploy-ops-con.adoc index 2484efd099fb..7890b48e4d86 100644 --- a/modules/microshift-olm-deploy-ops-con.adoc +++ b/modules/microshift-olm-deploy-ops-con.adoc @@ -10,14 +10,14 @@ After you create and deploy your custom catalog, you must create a Subscription [IMPORTANT] ==== -Operators in OLM have a watch scope. For example, some Operators only support watching their own namespace, while others support watching every namespace in the cluster. All Operators installed in a given namespace must have the same watch scope. +Operators in OLM have a watch scope. For example, some Operators only support watching their own namespace, while others support watching every namespace in the node. All Operators installed in a given namespace must have the same watch scope. ==== [id="microshift-olm-operators-connection-details_{context}"] == Connectivity and OLM Operator deployment Operators can be deployed anywhere a catalog is running. -* For clusters that are connected to the internet, mirroring images is not required. Images can be pulled over the network. +* For a node that is connected to the internet, mirroring images is not required. Images can be pulled over the network. * For restricted networks in which {microshift-short} has access to an internal network only, images must be mirrored to an internal registry. -* For use cases in which {microshift-short} clusters are completely offline, all images must be embedded into an `osbuild` blueprint. +* For use cases in which a {microshift-short} node is completely offline, all images must be embedded into an `osbuild` blueprint. //TODO point to correct ref docs \ No newline at end of file diff --git a/modules/microshift-olm-deploy-ops-global-ns.adoc b/modules/microshift-olm-deploy-ops-global-ns.adoc index d981c487edd8..461d7b3f4fe0 100644 --- a/modules/microshift-olm-deploy-ops-global-ns.adoc +++ b/modules/microshift-olm-deploy-ops-global-ns.adoc @@ -4,9 +4,9 @@ :_mod-docs-content-type: PROCEDURE [id="microshift-OLM-deploy-Operators_{context}"] -= Adding OLM-based Operators to a networked cluster using the global namespace += Adding OLM-based Operators to a networked node using the global namespace -To deploy different operators to different namespaces, use this procedure. For {microshift-short} clusters that have network connectivity, Operator Lifecycle Manager (OLM) can access sources hosted on remote registries. The following procedure lists the basic steps of using configuration files to install an Operator that uses the global namespace. +To deploy different operators to different namespaces, use this procedure. For a {microshift-short} node that has network connectivity, Operator Lifecycle Manager (OLM) can access sources hosted on remote registries. The following procedure lists the basic steps of using configuration files to install an Operator that uses the global namespace. [NOTE] ==== diff --git a/modules/microshift-olm-deploy-ops-spec-ns.adoc b/modules/microshift-olm-deploy-ops-spec-ns.adoc index dd85a9d3be57..30727e701be7 100644 --- a/modules/microshift-olm-deploy-ops-spec-ns.adoc +++ b/modules/microshift-olm-deploy-ops-spec-ns.adoc @@ -4,9 +4,9 @@ :_mod-docs-content-type: PROCEDURE [id="microshift-OLM-deploy-Operators-specific-namespace_{context}"] -= Adding OLM-based Operators to a networked cluster in a specific namespace += Adding OLM-based Operators to a networked node in a specific namespace -Use this procedure if you want to specify a namespace for an Operator, for example, `olm-microshift`. In this example, the catalog is scoped and available in the global `openshift-marketplace` namespace. The Operator uses content from the global namespace, but runs only in the `olm-microshift` namespace. For {microshift-short} clusters that have network connectivity, Operator Lifecycle Manager (OLM) can access sources hosted on remote registries. +Use this procedure if you want to specify a namespace for an Operator, for example, `olm-microshift`. In this example, the catalog is scoped and available in the global `openshift-marketplace` namespace. The Operator uses content from the global namespace, but runs only in the `olm-microshift` namespace. For a {microshift-short} node that has network connectivity, Operator Lifecycle Manager (OLM) can access sources hosted on remote registries. [IMPORTANT] ==== diff --git a/modules/microshift-ops-config-embed-ostree.adoc b/modules/microshift-ops-config-embed-ostree.adoc index 61ae87ca4be5..badbff374310 100644 --- a/modules/microshift-ops-config-embed-ostree.adoc +++ b/modules/microshift-ops-config-embed-ostree.adoc @@ -67,7 +67,7 @@ spec: You must use the SHA instead of a tag in your catalog CR or the pod fails to start. ==== -. Apply the YAML file from the oc-mirror plugin dry run results directory to the cluster by running the following command: +. Apply the YAML file from the oc-mirror plugin dry run results directory to the node by running the following command: + [source,terminal] ---- diff --git a/modules/microshift-opt-out-telemetry.adoc b/modules/microshift-opt-out-telemetry.adoc index 2d2f210fef19..6256a0a45e88 100644 --- a/modules/microshift-opt-out-telemetry.adoc +++ b/modules/microshift-opt-out-telemetry.adoc @@ -1,17 +1,17 @@ // Module included in the following assemblies: // -// microshift_support/microshift-remote-cluster-monitoring.adoc +// microshift_support/microshift-remote-node-monitoring.adoc :_mod-docs-content-type: PROCEDURE [id="microshift-opt-out-telemetry_{context}"] = Opting out of Telemetry for {microshift-short} -If your cluster is not connected to a network, or you do not want Telemetry gathered, you can easily opt out of Telemetry by disabling the parameter in the {microshift-short} configuration file. +If your node is not connected to a network, or you do not want Telemetry gathered, you can opt out of Telemetry by disabling the parameter in the {microshift-short} configuration file. .Prerequisties * You installed {oc-first}. -* You have root access to the cluster. +* You have root access to the node. .Procedure @@ -38,5 +38,3 @@ telemetry: status: Disabled # ... ---- - -//Should the user also delete the endpoint, or does that not matter? \ No newline at end of file diff --git a/modules/microshift-otel-config-examples.adoc b/modules/microshift-otel-config-examples.adoc index 4d636f699d1c..729b7511c60b 100644 --- a/modules/microshift-otel-config-examples.adoc +++ b/modules/microshift-otel-config-examples.adoc @@ -8,7 +8,7 @@ The amount and complexity of the data depends on predefined configurations. These configurations determine the number of data sources and the amount of collected data that is transmitted. These configurations are defined as small, medium, and large (default). -The `opentelemetry-collector.yaml` file includes specific parameters that are used to collect data for monitoring the system resources. All warnings for cluster events are included in the collected data. {microshift-short} Observability collects and transmits data for the following resources: +The `opentelemetry-collector.yaml` file includes specific parameters that are used to collect data for monitoring the system resources. All warnings for node events are included in the collected data. {microshift-short} Observability collects and transmits data for the following resources: * CPU, memory, disk, and network metrics of containers, pods, and nodes * Kubernetes events @@ -16,4 +16,4 @@ The `opentelemetry-collector.yaml` file includes specific parameters that are us * System journals for certain {microshift-short} services, and dependencies * Metrics exposed by pods that have the `prometheus.io/scrape`: `true` annotation -Replace the values of the `exporters.otlp.endpoint` and `services.telemetry.metrics.readers[0].endpoint` fields with the IP address or host name of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} observability service logs. \ No newline at end of file +Replace the values of the `exporters.otlp.endpoint` and `services.telemetry.metrics.readers[0].endpoint` fields with the IP address or hostname of the remote back end. This IP address resolves to the local node's host name. Any unreachable endpoint is reported in the {microshift-short} observability service logs. \ No newline at end of file diff --git a/modules/microshift-ovs-snapshot.adoc b/modules/microshift-ovs-snapshot.adoc index 71b4d66de83f..9e5344f37d81 100644 --- a/modules/microshift-ovs-snapshot.adoc +++ b/modules/microshift-ovs-snapshot.adoc @@ -4,20 +4,20 @@ :_mod-docs-content-type: PROCEDURE [id="microshift-OVS-snapshot_{context}"] -= Getting a snapshot of OVS interfaces from a running cluster += Getting a snapshot of OVS interfaces from a running node A snapshot represents the state and data of OVS interfaces at a specific point in time. .Procedure -* To see a snapshot of OVS interfaces from a running {microshift-short} cluster, use the following command: +* To see a snapshot of OVS interfaces from a running {microshift-short} node, use the following command: + [source,terminal] ---- $ sudo ovs-vsctl show ---- + -.Example OVS interfaces in a running cluster +.Example OVS interfaces in a running node [source,terminal] ---- 9d9f5ea2-9d9d-4e34-bbd2-dbac154fdc93 diff --git a/modules/microshift-preparing-for-image-building-bootc.adoc b/modules/microshift-preparing-for-image-building-bootc.adoc index 55cbcd93a219..b296fbb5d72f 100644 --- a/modules/microshift-preparing-for-image-building-bootc.adoc +++ b/modules/microshift-preparing-for-image-building-bootc.adoc @@ -6,7 +6,7 @@ [id="microshift-preparing-for-image-building_{context}"] = Preparing for bootc image building -Use the image builder tool to compose customized {microshift-short} bootc images optimized for edge deployments. You can run a {microshift-short} cluster with your applications on a {op-system-image} virtual machine for development and testing first, then use your whole solution in edge production environments. +Use the image builder tool to compose customized {microshift-short} bootc images optimized for edge deployments. You can run a {microshift-short} node with your applications on a {op-system-image} virtual machine for development and testing first, then use your whole solution in edge production environments. Use the following {op-system-base} documentation to understand the full details of using {op-system-image}: diff --git a/modules/microshift-preparing-for-image-building.adoc b/modules/microshift-preparing-for-image-building.adoc index aa8a43475c20..a9a29a9a4985 100644 --- a/modules/microshift-preparing-for-image-building.adoc +++ b/modules/microshift-preparing-for-image-building.adoc @@ -6,7 +6,7 @@ [id="microshift-preparing-for-image-building_{context}"] = Preparing for image building -Use the image builder tool to compose customized {op-system-ostree-first} images optimized for edge deployments. You can run a {microshift-short} cluster with your applications on a {op-system-ostree} virtual machine for development and testing first, then use your whole solution in edge production environments. +Use the image builder tool to compose customized {op-system-ostree-first} images optimized for edge deployments. You can run a {microshift-short} node with your applications on a {op-system-ostree} virtual machine for development and testing first, then use your whole solution in edge production environments. Use the following {op-system-base} documentation to understand the full details of using {op-system-ostree}: diff --git a/modules/microshift-preparing-to-make-app-rpms.adoc b/modules/microshift-preparing-to-make-app-rpms.adoc index 986c310758a9..6eff1b936115 100644 --- a/modules/microshift-preparing-to-make-app-rpms.adoc +++ b/modules/microshift-preparing-to-make-app-rpms.adoc @@ -6,7 +6,7 @@ [id="microshift-preparing-to-make-app-rpms_{context}"] = Preparing to make application RPMs -To build your own RPMs, choose a tool of your choice, such as the `rpmbuild` tool, and initialize the RPM build tree in your home directory. The following is an example procedure. As long as your RPMs are accessible to image builder, you can use the method you prefer to build the application RPMs. +To build your own RPMs, choose a tool of your choice, such as the `rpmbuild` tool, and initialize the RPM build tree in your home directory. The following is an example procedure. If your RPMs are accessible to image builder, you can use the method you prefer to build the application RPMs. .Prerequisites diff --git a/modules/microshift-proc-configuring-generic-device-plugin.adoc b/modules/microshift-proc-configuring-generic-device-plugin.adoc index e8f7b8f890de..85c1aad01629 100644 --- a/modules/microshift-proc-configuring-generic-device-plugin.adoc +++ b/modules/microshift-proc-configuring-generic-device-plugin.adoc @@ -18,7 +18,7 @@ The Generic Device Plugin (GDP) is disabled by default in {microshift-short}. To * You created a custom `config.yaml` file in the `/etc/microshift` directory. * You installed the {oc-first}. * You have `sudo` privileges on the {microshift-short} host. -* You have identified the specific host devices that you want to expose to your {microshift-short} cluster. For example, `/dev/video0`, `/dev/ttyUSB*`, or USB Vendor/Product IDs. +* You have identified the specific host devices that you want to expose to your {microshift-short} node. For example, `/dev/video0`, `/dev/ttyUSB*`, or USB Vendor/Product IDs. .Procedure @@ -84,7 +84,7 @@ Allow some time for {microshift-short} to restart and for the GDP to register it .Verification -* You can check the available devices in your cluster by running the following command: +* You can check the available devices in your node by running the following command: + [source,terminal,subs="+quotes"] ---- @@ -92,7 +92,7 @@ $ oc describe node __ | grep "device.microshift.io" <1> ---- <1> Replace __ with your node name. + -* Depending on your configuration, expect output that indicates that the devices are now discoverable and schedulable within your {microshift-short} cluster. +* Depending on your configuration, expect output that indicates that the devices are now discoverable and schedulable within your {microshift-short} node. + .Example output [source,terminal] diff --git a/modules/microshift-proc-deploying-applications-with-generic-devices.adoc b/modules/microshift-proc-deploying-applications-with-generic-devices.adoc index 331adb008114..2417858ffa50 100644 --- a/modules/microshift-proc-deploying-applications-with-generic-devices.adoc +++ b/modules/microshift-proc-deploying-applications-with-generic-devices.adoc @@ -39,7 +39,7 @@ spec: drop: ["ALL"] runAsNonRoot: true seccompProfile: - type: "RuntimeDefault" + type: "RuntimeDefault" ---- <1> Replace with your container image. <2> Replace with the command for your application. @@ -48,7 +48,7 @@ spec: <5> A request for one instance of the `video` device. <6> Define and configure with the least privilege value to ensure that the container has only required permissions, such as access to the device file, and to restrict other capabilities for the container. + -. Deploy the Kubernetes workload by applying the manifest to the {microshift-short} cluster by running the following command: +. Deploy the Kubernetes workload by applying the manifest to the {microshift-short} node by running the following command: + [source,terminal,subs="+quotes"] ---- diff --git a/modules/microshift-ref-generic-device-plugin-configuration-parameters.adoc b/modules/microshift-ref-generic-device-plugin-configuration-parameters.adoc index 662965c05017..1d2ad1a809b4 100644 --- a/modules/microshift-ref-generic-device-plugin-configuration-parameters.adoc +++ b/modules/microshift-ref-generic-device-plugin-configuration-parameters.adoc @@ -70,7 +70,7 @@ When unspecified, `Permissions` defaults to `mrw`. |A unique string representing the kind of device this specification describes, for example, `serial`, `video`, or `fuse`. This name is used in pod resource requests, for example, `device.microshift.io/serial`. |`domain` -|`domain` is a subgroup that specifies the domain prefix with which devices are advertised and present in the cluster. For example, `device.microshift.io/serial`. The default value is `device.microshift.io`. +|`domain` is a subgroup that specifies the domain prefix with which devices are advertised and present in the node. For example, `device.microshift.io/serial`. The default value is `device.microshift.io`. |`status` |`status` is a subgroup that specifies the default GDP status. `Enabled` or `Disabled` are valid values. diff --git a/modules/microshift-ref-generic-device-plugin-troubleshooting.adoc b/modules/microshift-ref-generic-device-plugin-troubleshooting.adoc index 39e66d583260..448d6271eec9 100644 --- a/modules/microshift-ref-generic-device-plugin-troubleshooting.adoc +++ b/modules/microshift-ref-generic-device-plugin-troubleshooting.adoc @@ -6,4 +6,4 @@ [id="microshift-generic-device-plugin-troubleshooting_{context}"] = Troubleshooting configuration issues -If you encounter errors such as "invalid configuration: failed to parse device" or "cannot define both path and usbs at the same time", it means you have incorrectly mixed `paths` and `usbs` fields within the same `groups` entry for a device. Each `group` must exclusively use either `paths` or `usbs` to define its devices. \ No newline at end of file +If you encounter errors such as "invalid configuration: failed to parse device" or "cannot define both path and usbs at the same time", it means you have incorrectly mixed `paths` and `usbs` fields within the same `groups` entry for a device. Each `group` must exclusively use either `paths` or `usbs` to define its devices. diff --git a/modules/microshift-restart-ovnkube-master.adoc b/modules/microshift-restart-ovnkube-master.adoc index d27f0011f462..3b571876dac8 100644 --- a/modules/microshift-restart-ovnkube-master.adoc +++ b/modules/microshift-restart-ovnkube-master.adoc @@ -11,15 +11,15 @@ The following procedure restarts the `ovnkube-master` pod. .Prerequisites * The OpenShift CLI (`oc`) is installed. -* Access to the cluster as a user with the `cluster-admin` role. -* A cluster installed on infrastructure configured with the OVN-Kubernetes network plugin. +* You have root access to the node. +* A node installed on infrastructure configured with the OVN-Kubernetes network plugin. * The KUBECONFIG environment variable is set. .Procedure Use the following steps to restart the `ovnkube-master` pod. -. Access the remote cluster by running the following command: +. Access the remote node by running the following command: + [source,terminal] ---- diff --git a/modules/microshift-restoring-backups-auto-recovery.adoc b/modules/microshift-restoring-backups-auto-recovery.adoc index 4d4a8247fbaa..85f0656c4808 100644 --- a/modules/microshift-restoring-backups-auto-recovery.adoc +++ b/modules/microshift-restoring-backups-auto-recovery.adoc @@ -6,7 +6,7 @@ [id="microshift-restoring-backups-auto-recovery_{context}"] = Restoring backups using the auto-recovery feature -You can restore backups after system events that remove or damage required data. Use the following procedure to restore backups using automatic recovery. Automatic recovery selects the most recent backup and restores it. Previously restored backups that used automatic recovery are moved to your `PATH/restored` directory. +You can restore backups after system events that remove or damage required data. Use the following procedure to restore backups by using automatic recovery. Automatic recovery selects the most recent backup and restores it. Previously restored backups that used automatic recovery are moved to your `PATH/restored` directory. .Prerequisites diff --git a/modules/microshift-restoring-data-backups.adoc b/modules/microshift-restoring-data-backups.adoc index dc8fe464c22b..79131adb0e4f 100644 --- a/modules/microshift-restoring-data-backups.adoc +++ b/modules/microshift-restoring-data-backups.adoc @@ -53,7 +53,7 @@ $ sudo microshift restore /mnt/__/_ 80/TCP 119s .Next step -* Create a `Route` object so that your applications can reach the {microshift-short} cluster. +* Create a `Route` object so that your applications can reach the {microshift-short} node. diff --git a/modules/microshift-rhoai-query-model.adoc b/modules/microshift-rhoai-query-model.adoc index bfa6769162de..26d3eee79e5a 100644 --- a/modules/microshift-rhoai-query-model.adoc +++ b/modules/microshift-rhoai-query-model.adoc @@ -10,7 +10,7 @@ Make an inference request against the AI model server that is using the `ovms-re .Prerequisites -* The {microshift-short} cluster is running. +* {microshift-short} is running. * You configured the model-serving runtime. * You uploaded your AI model to {microshift-short}. diff --git a/modules/microshift-rhoai-serving-ai-models-con.adoc b/modules/microshift-rhoai-serving-ai-models-con.adoc index cbfbde6b6978..29d097714d05 100644 --- a/modules/microshift-rhoai-serving-ai-models-con.adoc +++ b/modules/microshift-rhoai-serving-ai-models-con.adoc @@ -32,9 +32,9 @@ Workflow for configuring a model-serving runtime:: * Create the `ServingRuntime` CR in your workload namespace. //CRD is shipped with product; the CR is what users are creating. -* If the {microshift-short} cluster is already running, you can export the required `ServingRuntime` CR to a file and edit it. +* If the {microshift-short} node is already running, you can export the required `ServingRuntime` CR to a file and edit it. -* If the {microshift-short} cluster is not running, or if you want to manually prepare a manifest, you can use the original definition on the disk, which is part of the `microshift-ai-model-serving` RPM. +* If the {microshift-short} node is not running, or if you want to manually prepare a manifest, you can use the original definition on the disk, which is part of the `microshift-ai-model-serving` RPM. * Create the `InferenceService` CR in your workload namespace. //CRD is shipped with product; the CR is what users are creating. diff --git a/modules/microshift-rhoai-servingruntimes-ex.adoc b/modules/microshift-rhoai-servingruntimes-ex.adoc index e7a3789f1066..4f5bf95f713f 100644 --- a/modules/microshift-rhoai-servingruntimes-ex.adoc +++ b/modules/microshift-rhoai-servingruntimes-ex.adoc @@ -10,7 +10,7 @@ Create a `ServingRuntime` custom resource (CR) based on installed manifests and [NOTE] ==== -This approach does not require a live cluster, so it can be part of CI/CD automation. +This approach does not require a live node, so it can be part of CI/CD automation. ==== .Prerequisites diff --git a/modules/microshift-rhoai-verify-model-connected.adoc b/modules/microshift-rhoai-verify-model-connected.adoc index 37d772650577..56e7737b530f 100644 --- a/modules/microshift-rhoai-verify-model-connected.adoc +++ b/modules/microshift-rhoai-verify-model-connected.adoc @@ -12,12 +12,12 @@ Before querying the model through the API, you can check to be certain that the * You configured the AI model-serving runtime. * You uploaded your AI model to {microshift-short}. -* The {microshift-short} cluster is running. +* {microshift-short} is running. * You installed {oc-first}. .Procedure -. Get the IP address of the {microshift-short} cluster and assign it to the `IP` variable as the following example command shows: +. Get the IP address of the {microshift-short} node and assign it to the `IP` variable as the following example command shows: + [source,terminal] ---- diff --git a/modules/microshift-rhoai-workflow.adoc b/modules/microshift-rhoai-workflow.adoc index 0f93e1ed5630..c9179a489e1f 100644 --- a/modules/microshift-rhoai-workflow.adoc +++ b/modules/microshift-rhoai-workflow.adoc @@ -43,7 +43,7 @@ Getting ready to deploy:: ** Create the `InferenceService` CR. -* Optional: Create a `Route` object so that your model can connect outside the cluster. +* Optional: Create a `Route` object so that your model can connect outside the node. Using your model:: diff --git a/modules/microshift-security-context-constraints-opting.adoc b/modules/microshift-security-context-constraints-opting.adoc index 56c5fa7838a4..6b323cd5a60f 100644 --- a/modules/microshift-security-context-constraints-opting.adoc +++ b/modules/microshift-security-context-constraints-opting.adoc @@ -12,7 +12,7 @@ System defaults are not enforced when the `security.openshift.io/scc.podSecurity [IMPORTANT] ==== -Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. These namespaces include: +Namespaces that are defined as part of the node payload have pod security admission synchronization disabled permanently. These namespaces include: * `default` * `kube-node-lease` @@ -22,7 +22,7 @@ Namespaces that are defined as part of the cluster payload have pod security adm * All system-created namespaces that are prefixed with `openshift-`, except for `openshift-operators` By default, all namespaces that have an `openshift-` prefix are not synchronized. You can enable synchronization for any user-created [x-]`openshift-*` namespaces. You cannot enable synchronization for any system-created [x-]`openshift-*` namespaces, except for `openshift-operators`. -If an Operator is installed in a user-created `openshift-*` namespace, synchronization is turned on by default after a cluster service version (CSV) is created in the namespace. The synchronized label inherits the permissions of the service accounts in the namespace. +If an Operator is installed in a user-created `openshift-*` namespace, synchronization is turned on by default after a node service version (CSV) is created in the namespace. The synchronized label inherits the permissions of the service accounts in the namespace. ==== .Procedure diff --git a/modules/microshift-security-context-constraints.adoc b/modules/microshift-security-context-constraints.adoc index dfff1cb4e2ec..d0395ebb569e 100644 --- a/modules/microshift-security-context-constraints.adoc +++ b/modules/microshift-security-context-constraints.adoc @@ -13,7 +13,7 @@ In addition to the global pod security admission control configuration, a contro [IMPORTANT] ==== -Namespaces that are defined as part of the cluster payload have pod security admission synchronization disabled permanently. You can enable pod security admission synchronization on other namespaces as necessary. If an Operator is installed in a user-created `openshift-*` namespace, synchronization is turned on by default after a cluster service version (CSV) is created in the namespace. +Namespaces that are defined as part of the node payload have pod security admission synchronization disabled permanently. You can enable pod security admission synchronization on other namespaces as necessary. If an Operator is installed in a user-created `openshift-*` namespace, synchronization is turned on by default after a cluster service version (CSV) is created in the namespace. ==== The controller examines `ServiceAccount` object permissions to use security context constraints in each namespace. Security context constraints (SCCs) are mapped to pod security profiles based on their field values; the controller uses these translated profiles. Pod security admission `warn` and `audit` labels are set to the most privileged pod security profile found in the namespace to prevent warnings and audit logging as pods are created. diff --git a/modules/microshift-storage-about-vol-snapshots.adoc b/modules/microshift-storage-about-vol-snapshots.adoc index ad2630decf5d..d07582570474 100644 --- a/modules/microshift-storage-about-vol-snapshots.adoc +++ b/modules/microshift-storage-about-vol-snapshots.adoc @@ -6,7 +6,7 @@ [id="about-volume-snapshots_{context}"] = About volume snapshots -You can use volume snapshots with logical volume manager (LVM) thin volumes to help protect against data loss from applications running in a {microshift-short} cluster. {microshift-short} only supports the logical volume manager storage (LVMS) Container Storage Interface (CSI) provider. +You can use volume snapshots with logical volume manager (LVM) thin volumes to help protect against data loss from applications running in a {microshift-short} node. {microshift-short} only supports the logical volume manager storage (LVMS) Container Storage Interface (CSI) provider. [NOTE] ==== diff --git a/modules/microshift-storage-backup-volume-snapshots.adoc b/modules/microshift-storage-backup-volume-snapshots.adoc index f4a8a586a33a..293720ee3bdf 100644 --- a/modules/microshift-storage-backup-volume-snapshots.adoc +++ b/modules/microshift-storage-backup-volume-snapshots.adoc @@ -6,7 +6,7 @@ [id="microshift-storage-backup-vol-snaps_{context}"] = Backing up a volume snapshot -Snapshots of data from applications running on a {microshift-short} cluster are created as read-only logical volumes (LVs) located on the same devices as the original data. You must manually mount local volumes before they can be copied as persistent volumes (PVs) and used as backup copies. To use a snapshot of a {microshift-short} storage volume as a backup, find it on the local host and then move it to a secure location. +Snapshots of data from applications running on a {microshift-short} node are created as read-only logical volumes (LVs) located on the same devices as the original data. You must manually mount local volumes before they can be copied as persistent volumes (PVs) and used as backup copies. To use a snapshot of a {microshift-short} storage volume as a backup, find it on the local host and then move it to a secure location. To find specific snapshots and copy them, use the following procedure. diff --git a/modules/microshift-storage-classes.adoc b/modules/microshift-storage-classes.adoc index 0c27b5d3248a..b25c075f77f8 100644 --- a/modules/microshift-storage-classes.adoc +++ b/modules/microshift-storage-classes.adoc @@ -29,7 +29,7 @@ reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer <4> allowVolumeExpansion: <5> ---- -<1> An example of the default storage class. If a PVC does not specify a storage class, this class is assumed. There can only be one default storage class in a cluster. Having no value assigned to this annotation is also supported. +<1> An example of the default storage class. If a PVC does not specify a storage class, this class is assumed. There can only be one default storage class in a {microshift-short} node. Having no value assigned to this annotation is also supported. <2> Specifies which file system to provision on the volume. Options are "xfs" and "ext4". <3> Identifies which provisioner should manage this class. <4> Specifies whether to provision the volume before a client pod is present or immediately. Options are `WaitForFirstConsumer` and `Immediate`. `WaitForFirstConsumer` is recommended to ensure that storage is only provisioned for pods that can be scheduled. diff --git a/modules/microshift-storage-creating-vol-snapshot.adoc b/modules/microshift-storage-creating-vol-snapshot.adoc index 24fe217a73ab..d2e8e6ceab3e 100644 --- a/modules/microshift-storage-creating-vol-snapshot.adoc +++ b/modules/microshift-storage-creating-vol-snapshot.adoc @@ -6,11 +6,11 @@ [id="creating-a-volume-snapshotting_{context}"] = Creating a volume snapshot -To create a snapshot of a {microshift-short} storage volume, you must first configure {op-system-ostree} and the cluster. In the following example procedure, the pod that the source volume is mounted to is deleted. Deleting the pod prevents data from being written to it during snapshot creation. Ensuring that no data is being written during a snapshot is crucial to creating a viable snapshot. +To create a snapshot of a {microshift-short} storage volume, you must first configure {op-system-ostree} and the node. In the following example procedure, the pod that the source volume is mounted to is deleted. Deleting the pod prevents data from being written to it during snapshot creation. Ensuring that no data is being written during a snapshot is crucial to creating a viable snapshot. .Prerequisites -* User has root access to a {microshift-short} cluster. -* A {microshift-short} cluster is running. +* User has root access to a {microshift-short} node. +* {microshift-short} is running. * A device class defines an LVM thin-pool. * A `volumeSnapshotClass` specifies `driver: topolvm.io`. * Any workload attached to the source PVC is paused or deleted. This helps avoid data corruption. diff --git a/modules/microshift-storage-vol-snapshot-class.adoc b/modules/microshift-storage-vol-snapshot-class.adoc index 7fb7157389d1..918c732c02bb 100644 --- a/modules/microshift-storage-vol-snapshot-class.adoc +++ b/modules/microshift-storage-vol-snapshot-class.adoc @@ -6,7 +6,7 @@ [id="microshift-volume-snapshot-classes_{context}"] = Volume snapshot classes -Snapshotting is a CSI storage feature supported by LVMS. To enable dynamic snapshotting, at least one `VolumeSnapshotClass` configuration file must be present on the cluster. +Snapshotting is a CSI storage feature supported by LVMS. To enable dynamic snapshotting, at least one `VolumeSnapshotClass` configuration file must be present on the node. [IMPORTANT] ==== diff --git a/modules/microshift-tls-config-proc.adoc b/modules/microshift-tls-config-proc.adoc index 686869fff3c2..03f1e20b7b93 100644 --- a/modules/microshift-tls-config-proc.adoc +++ b/modules/microshift-tls-config-proc.adoc @@ -10,9 +10,9 @@ You can choose to use either the TLS 1.2 or TLS 1.3 security profiles with {micr .Prerequisites -* You have access to the cluster as a root user. +* You have access to the node as a root user. * {microshift-short} has either not started for the first time, or is stopped. -* The OpenShift CLI (`oc`) is installed. +* The {oc-first} is installed. * The certificate authority has issued the custom certificates (CAs). .Procedure diff --git a/modules/microshift-uninstall-microshift-rpms.adoc b/modules/microshift-uninstall-microshift-rpms.adoc index df71d5b4e74f..89ad675f900d 100644 --- a/modules/microshift-uninstall-microshift-rpms.adoc +++ b/modules/microshift-uninstall-microshift-rpms.adoc @@ -10,7 +10,7 @@ * You are logged into {microshift-short} as an administrator with root-user access. * You have filed a support case. -* You have root access to the {microshift-short} cluster. +* You have root access to the {microshift-short} node. .Procedure diff --git a/modules/microshift-uninstalling-lvms-csi-driver.adoc b/modules/microshift-uninstalling-lvms-csi-driver.adoc index 0a3b02a8ff8d..78f00de1f489 100644 --- a/modules/microshift-uninstalling-lvms-csi-driver.adoc +++ b/modules/microshift-uninstalling-lvms-csi-driver.adoc @@ -11,7 +11,7 @@ To uninstall the installed CSI driver implementation, use the following procedur .Prerequisites * {microshift-short} is installed and running. -* The CSI driver implementation is deployed on the MicroShift cluster. +* The CSI driver implementation is deployed on the {microshift-short} node. .Procedure diff --git a/modules/microshift-uninstalling-lvms-csi-snapshot.adoc b/modules/microshift-uninstalling-lvms-csi-snapshot.adoc index b4efeecbae8f..e4d6d6ab5909 100644 --- a/modules/microshift-uninstalling-lvms-csi-snapshot.adoc +++ b/modules/microshift-uninstalling-lvms-csi-snapshot.adoc @@ -11,7 +11,7 @@ To uninstall the installed CSI snapshot implementation, use the following proced .Prerequisites * {microshift-short} is installed and running. -* The CSI snapshot implementation is deployed on the {microshift-short} cluster. +* The CSI snapshot implementation is deployed on the {microshift-short} node. .Procedure diff --git a/modules/microshift-updates-rpms-ostree-con.adoc b/modules/microshift-updates-rpms-ostree-con.adoc index 595de1e78545..359ad1614781 100644 --- a/modules/microshift-updates-rpms-ostree-con.adoc +++ b/modules/microshift-updates-rpms-ostree-con.adoc @@ -11,7 +11,7 @@ Updating {microshift-short} on a {op-system-ostree-first} system requires buildi The procedures are the same for minor-version and patch updates. For example, use the same steps to upgrade from 4.18 to 4.19 or from 4.19.2 to 4.19.3. The following details apply: * Back up and system rollback are automatic with this update type. -* You can use the following workflow to update applications running in the {microshift-short} cluster. Ensure compatibilities between the application and the adjacent versions of {microshift-short} and {op-system-ostree} before starting an update. +* You can use the following workflow to update applications running in the {microshift-short} node. Ensure compatibilities between the application and the adjacent versions of {microshift-short} and {op-system-ostree} before starting an update. * Downgrades other than automatic rollbacks are not supported. The following procedure is for updates only. + [IMPORTANT] diff --git a/modules/microshift-viewing-audit-logs.adoc b/modules/microshift-viewing-audit-logs.adoc index a0d2161c911e..35f92f0f3636 100644 --- a/modules/microshift-viewing-audit-logs.adoc +++ b/modules/microshift-viewing-audit-logs.adoc @@ -11,7 +11,7 @@ You can identify pod security admission violations on a workload by viewing the .Prerequisites * You have installed `jq`. -* You have access to the cluster as a user with the `cluster-admin` role. +* You have root access to the node. .Procedure