Update node docs

apinnick · apinnick · commit 46d158f7b841 · 2023-08-10T18:14:21.000+03:00
Signed-off-by: Avital Pinnick &lt;apinnick@redhat.com&gt;
diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
@@ -3777,7 +3777,7 @@ Topics:
   - Name: Using DPDK with SR-IOV
     File: virt-using-dpdk-with-sriov
   - Name: Hot plugging secondary network interfaces
-    File: virt-hot-plugging-network-interfaces 
+    File: virt-hot-plugging-network-interfaces
   - Name: Connecting a VM to a service mesh
     File: virt-connecting-vm-to-service-mesh
   - Name: Configuring a dedicated network for live migration
@@ -3824,13 +3824,11 @@ Topics:
   - Name: Configuring live migration policies
     File: virt-configuring-live-migration-policies
 # Node maintenance mode
-- Name: Node maintenance
-  Dir: node_maintenance
+- Name: Nodes
+  Dir: nodes
   Topics:
   - Name: About node maintenance
     File: virt-about-node-maintenance
-  - Name: Automatic renewal of TLS certificates
-    File: virt-automatic-certificates
   - Name: Managing node labeling for obsolete CPU models
     File: virt-managing-node-labeling-obsolete-cpu-models
   - Name: Preventing node reconciliation
diff --git a/modules/virt-about-node-labeling-cpu-features.adoc b/modules/virt-about-node-labeling-cpu-features.adoc
@@ -1,5 +1,5 @@
 // Module included in the following assemblies:
-// * virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc
+// * virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc
 
 :_content-type: CONCEPT
 [id="virt-about-node-labeling-cpu-features_{context}"]
diff --git a/modules/virt-about-node-labeling-obsolete-cpu-models.adoc b/modules/virt-about-node-labeling-obsolete-cpu-models.adoc
@@ -1,5 +1,5 @@
 // Module included in the following assemblies:
-// * virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc
+// * virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc
 
 :_content-type: CONCEPT
 [id="virt-about-node-labeling-obsolete-cpu-models_{context}"]
diff --git a/modules/virt-about-node-maintenance.adoc b/modules/virt-about-node-maintenance.adoc
@@ -1,5 +1,5 @@
 // Module included in the following assemblies:
-// virt/node_maintenance/virt-about-node-maintenance.adoc
+// virt/nodes/virt-about-node-maintenance.adoc
 
 :_content-type: CONCEPT
 [id="virt-about-node-maintenance_{context}"]
diff --git a/modules/virt-about-runstrategies-vms.adoc b/modules/virt-about-runstrategies-vms.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * virt/node_maintenance/virt-about-node-maintenance.adoc
+// * virt/nodes/virt-about-node-maintenance.adoc
 
 :_content-type: CONCEPT
 [id="virt-about-runstrategies-vms_{context}"]
diff --git a/modules/virt-additional-scc-for-kubevirt-controller.adoc b/modules/virt-additional-scc-for-kubevirt-controller.adoc
@@ -4,7 +4,7 @@
 
 :_content-type: REFERENCE
 [id="virt-additional-scc-for-kubevirt-controller_{context}"]
-= Additional {product-title} security context constraints and Linux capabilities for the kubevirt-controller service account
+= Additional SCCs and permissions for the kubevirt-controller service account
 
 Security context constraints (SCCs) control permissions for pods. These permissions include actions that a pod, a collection of containers, 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.
 
@@ -20,12 +20,12 @@ This allows virtual machines to use the hostpath volume plugin.
 * `scc.AllowPrivilegedContainer = false` +
 This ensures the virt-launcher pod is not run as a privileged container.
 
-* `scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}` +
+* `scc.AllowedCapabilities = []corev1.Capability{"SYS_NICE", "NET_BIND_SERVICE"}`
 
 ** `SYS_NICE` allows setting the CPU affinity.
 ** `NET_BIND_SERVICE` allows DHCP and Slirp operations.
 
-== Viewing the SCC and RBAC definitions for the kubevirt-controller
+.Viewing the SCC and RBAC definitions for the kubevirt-controller
 
 You can view the `SecurityContextConstraints` definition for the `kubevirt-controller` by using the `oc` tool:
 
diff --git a/modules/virt-automatic-certificates-renewal.adoc b/modules/virt-automatic-certificates-renewal.adoc
@@ -1,9 +1,13 @@
 // Module included in the following assemblies:
 //
-// * virt/node_maintenance/virt-automatic-certificates.adoc
+// * virt/about_virt/virt-security-policies.adoc
 
 [id="virt-automatic-certificates-renewal_{context}"]
-= TLS certificates automatic renewal schedules
+= TLS certificates
+
+TLS certificates for {VirtProductName} components are renewed and rotated automatically. You are not required to refresh them manually.
+
+.Automatic renewal schedules
 
 TLS certificates are automatically deleted and replaced according to the following schedule:
 
diff --git a/modules/virt-configuring-obsolete-cpu-models.adoc b/modules/virt-configuring-obsolete-cpu-models.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// * virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc
+// * virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc
 
 :_content-type: PROCEDURE
 [id="virt-configuring-obsolete-cpu-models_{context}"]
diff --git a/modules/virt-maintaining-bare-metal-nodes.adoc b/modules/virt-maintaining-bare-metal-nodes.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assemblies:
 //
-// virt/node_maintenance/virt-about-node-maintenance.adoc
+// virt/nodes/virt-about-node-maintenance.adoc
 
 [id="virt-maintaining-bare-metal-nodes_{context}"]
 = Maintaining bare metal nodes
diff --git a/modules/virt-using-skip-node.adoc b/modules/virt-using-skip-node.adoc
@@ -1,6 +1,6 @@
 // Module included in the following assembly:
 //
-// * virt/node_maintenance/virt-preventing-node-reconciliation.adoc
+// * virt/nodes/virt-preventing-node-reconciliation.adoc
 //
 
 :_content-type: PROCEDURE
diff --git a/virt/about_virt/virt-security-policies.adoc b/virt/about_virt/virt-security-policies.adoc
@@ -10,10 +10,9 @@ Learn about {VirtProductName} security and authorization.
 
 .Key points
 * {VirtProductName} adheres to the `restricted` link:https://kubernetes.io/docs/concepts/security/pod-security-standards/#restricted[Kubernetes pod security standards] profile, which aims to enforce the current best practices for pod security.
-
 * Virtual machine (VM) workloads run as unprivileged pods.
-
 * xref:../../authentication/managing-security-context-constraints.adoc#security-context-constraints-about_configuring-internal-oauth[Security context constraints] (SCCs) are defined for the `kubevirt-controller` service account.
+* TLS certificates for {VirtProductName} components are renewed and rotated automatically.
 
 include::modules/virt-about-workload-security.adoc[leveloffset=+1]
 
@@ -26,11 +25,14 @@ include::modules/virt-additional-scc-for-kubevirt-controller.adoc[leveloffset=+1
 
 include::modules/virt-default-cluster-roles.adoc[leveloffset=+2]
 
+[discrete]
 [role="_additional-resources"]
-[id="additional-resources_{context}"]
+[id="additional-resources_authorization"]
 == Additional resources
 * xref:../../authentication/managing-security-context-constraints.adoc#security-context-constraints-about_configuring-internal-oauth[Managing security context constraints]
 * xref:../../authentication/using-rbac.adoc#using-rbac[Using RBAC to define and apply permissions]
 * xref:../../authentication/using-rbac.adoc#creating-cluster-role_using-rbac[Creating a cluster role]
 * xref:../../authentication/using-rbac.adoc#cluster-role-binding-commands_using-rbac[Cluster role binding commands]
-* xref:../../virt/virtual_machines/cloning_vms/virt-enabling-user-permissions-to-clone-datavolumes.adoc#virt-enabling-user-permissions-to-clone-datavolumes[Enabling user permissions to clone data volumes across namespaces]
+* xref:../../virt/virtual_machines/cloning_vms/virt-enabling-user-permissions-to-clone-datavolumes.adoc#virt-enabling-user-permissions-to-clone-datavolumes[Enabling user permissions to clone data volumes across namespaces]
+
+include::modules/virt-automatic-certificates-renewal.adoc[leveloffset=+1]
diff --git a/virt/install/preparing-cluster-for-virt.adoc b/virt/install/preparing-cluster-for-virt.adoc
@@ -143,7 +143,7 @@ You can configure one of the following high-availability (HA) options for your c
 +
 [NOTE]
 ====
-In {product-title} clusters installed using installer-provisioned infrastructure and with MachineHealthCheck properly configured, if a node fails the MachineHealthCheck and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See xref:../../virt/node_maintenance/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[About RunStrategies for virtual machines] for more detailed information about the potential outcomes and how RunStrategies affect those outcomes.
+In {product-title} clusters installed using installer-provisioned infrastructure and with MachineHealthCheck properly configured, if a node fails the MachineHealthCheck and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See xref:../../virt/nodes/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[About RunStrategies for virtual machines] for more detailed information about the potential outcomes and how RunStrategies affect those outcomes.
 ====
 
 * Automatic high availability for both IPI and non-IPI is available by using the *Node Health Check Operator* on the {product-title} cluster to deploy the `NodeHealthCheck` controller. The controller identifies unhealthy nodes and uses the Self Node Remediation Operator to remediate the unhealthy nodes. For more information on remediation, fencing, and maintaining nodes, see the link:https://access.redhat.com/documentation/en-us/workload_availability_for_red_hat_openshift/23.2/html-single/remediation_fencing_and_maintenance/index#about-remediation-fencing-maintenance[Workload Availability for Red Hat OpenShift] documentation.
diff --git a/virt/node_maintenance/virt-automatic-certificates.adoc b/virt/node_maintenance/virt-automatic-certificates.adoc
diff --git a/virt/nodes/_attributes b/virt/nodes/_attributes
diff --git a/virt/nodes/images b/virt/nodes/images
diff --git a/virt/nodes/modules b/virt/nodes/modules
diff --git a/virt/nodes/snippets b/virt/nodes/snippets
diff --git a/virt/nodes/virt-about-node-maintenance.adoc b/virt/nodes/virt-about-node-maintenance.adoc
diff --git a/virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc b/virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc
diff --git a/virt/nodes/virt-preventing-node-reconciliation.adoc b/virt/nodes/virt-preventing-node-reconciliation.adoc
@@ -14,4 +14,4 @@ include::modules/virt-using-skip-node.adoc[leveloffset=+1]
 [role="_additional-resources"]
 == Additional resources
 
-* xref:../../virt/node_maintenance/virt-managing-node-labeling-obsolete-cpu-models.adoc#virt-managing-node-labeling-obsolete-cpu-models[Managing node labeling for obsolete CPU models]
+* xref:../../virt/nodes/virt-managing-node-labeling-obsolete-cpu-models.adoc#virt-managing-node-labeling-obsolete-cpu-models[Managing node labeling for obsolete CPU models]
diff --git a/virt/nodes/virt-triggering-vm-failover-resolving-failed-node.adoc b/virt/nodes/virt-triggering-vm-failover-resolving-failed-node.adoc
@@ -13,7 +13,7 @@ If a node fails and xref:../../machine_management/deploying-machine-health-check
 If you installed your cluster by using xref:../../installing/installing_bare_metal_ipi/ipi-install-overview.adoc#ipi-install-overview[installer-provisioned infrastructure] and you properly configured machine health checks, the following events occur:
 
 * Failed nodes are automatically recycled.
-* Virtual machines with xref:../../virt/node_maintenance/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[`runStrategy`] set to `Always` or `RerunOnFailure` are automatically scheduled on healthy nodes.
+* Virtual machines with xref:../../virt/nodes/virt-about-node-maintenance.adoc#virt-about-runstrategies-vms_virt-about-node-maintenance[`runStrategy`] set to `Always` or `RerunOnFailure` are automatically scheduled on healthy nodes.
 ====
 
 [id="prerequisites_{context}"]
diff --git a/virt/virtual_machines/advanced_vm_management/virt-high-availability-for-vms.adoc b/virt/virtual_machines/advanced_vm_management/virt-high-availability-for-vms.adoc
@@ -12,7 +12,7 @@ You can enable high availability for virtual machines (VMs) by manually deleting
 
 If a node fails and machine health checks are not deployed on your cluster, virtual machines with `runStrategy: Always` configured are not automatically relocated to healthy nodes. To trigger VM failover, you must manually delete the `Node` object.
 
-See xref:../../../virt/node_maintenance/virt-triggering-vm-failover-resolving-failed-node.adoc#virt-triggering-vm-failover-resolving-failed-node[Deleting a failed node to trigger virtual machine failover].
+See xref:../../../virt/nodes/virt-triggering-vm-failover-resolving-failed-node.adoc#virt-triggering-vm-failover-resolving-failed-node[Deleting a failed node to trigger virtual machine failover].
 
 .Configuring remediating nodes
 
