BZ2187603: SCC and SA for DPDK checkup

Signed-off-by: Avital Pinnick <[email protected]>

Author: apinnick

modules/virt-checking-cluster-dpdk-readiness.adoc

@@ -4,19 +4,30 @@
 
 :_content-type: PROCEDURE
 [id="virt-checking-cluster-dpdk-readiness_{context}"]
-= Checking cluster readiness to run DPDK applications with zero packet loss
+= DPDK checkup
 
-Use a predefined checkup to verify if your {product-title} cluster node can run a virtual machine (VM) with a Data Plane Development Kit (DPDK) workload. The checkup runs traffic between a traffic generator pod and a VM running a test DPDK application, and checks for packet loss.
+Use a predefined checkup to verify that your {product-title} cluster node can run a virtual machine (VM) with a Data Plane Development Kit (DPDK) workload with zero packet loss. The DPDK checkup runs traffic between a traffic generator pod and a VM running a test DPDK application.
+
+You run a DPDK checkup by performing the following steps:
+
+. Create a service account, role, and role bindings for the DPDK checkup and a service account for the traffic generator pod.
+. Create a security context constraints resource for the traffic generator pod.
+. Create a config map to provide the input to run the checkup and to store the results.
+. Create a job to run the checkup.
+. Review the results in the config map.
+. Optional: To rerun the checkup, delete the existing config map and job and then create a new config map and job.
+. When you are finished, delete the DPDK checkup resources.
 
 .Prerequisites
 * You have access to the cluster as a user with `cluster-admin` permissions.
 * You have installed the OpenShift CLI (`oc`).
 * You have configured the compute nodes to run DPDK applications on VMs with zero packet loss.
 
 .Procedure
-. Create a manifest file that contains the `ServiceAccount`, `Role`, and `RoleBinding` objects with permissions that the checkup requires for cluster access:
+
+. Create a `ServiceAccount`, `Role`, and `RoleBinding` manifest for the DPDK checkup and the traffic generator pod:
 +
-.Example roles manifest
+.Example service account, role, and rolebinding manifest file
 [%collapsible]
 ====
 [source,yaml]
@@ -80,17 +91,71 @@ roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: Role
   name: kubevirt-dpdk-checker
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: dpdk-checkup-traffic-gen-sa
 ----
 ====
 
-. Apply the checkup roles manifest:
+. Apply the `ServiceAccount`, `Role`, and `RoleBinding` manifest:
++
+[source,terminal]
+----
+$ oc apply -n <target_namespace> -f <dpdk_sa_roles_rolebinding>.yaml
+----
+
+. Create a `SecurityContextConstraints` manifest for the traffic generator pod:
++
+.Example security context constraints manifest
+[source,yaml]
+----
+apiVersion: security.openshift.io/v1
+kind: SecurityContextConstraints
+metadata:
+  name: dpdk-checkup-traffic-gen
+allowHostDirVolumePlugin: true
+allowHostIPC: false
+allowHostNetwork: false
+allowHostPID: false
+allowHostPorts: false
+allowPrivilegeEscalation: false
+allowPrivilegedContainer: false
+allowedCapabilities:
+- IPC_LOCK
+- NET_ADMIN
+- NET_RAW
+- SYS_RESOURCE
+defaultAddCapabilities: null
+fsGroup:
+  type: RunAsAny
+groups: []
+readOnlyRootFilesystem: false
+requiredDropCapabilities: null
+runAsUser:
+  type: RunAsAny
+seLinuxContext:
+  type: RunAsAny
+seccompProfiles:
+- runtime/default
+- unconfined
+supplementalGroups:
+  type: RunAsAny
+users:
+- system:serviceaccount:dpdk-checkup-ns:dpdk-checkup-traffic-gen-sa
+volumes:
+- hostPath
+----
+
+. Apply the `SecurityContextConstraints` manifest:
 +
 [source,terminal]
 ----
-$ oc apply -n <target_namespace> -f <dpdk_roles>.yaml
+$ oc apply -f <dpdk_scc>.yaml
 ----
 
-. Create a `ConfigMap` manifest that contains the input parameters for the checkup. The config map also stores the results of the checkup.
+. Create a `ConfigMap` manifest that contains the input parameters for the checkup:
 +
 .Example input config map
 [source,yaml]
@@ -111,14 +176,14 @@ data:
 <3> The container image for the traffic generator. In this example, the image is pulled from the upstream Project Quay Container Registry.
 <4> The container disk image for the VM. In this example, the image is pulled from the upstream Project Quay Container Registry.
 
-. Apply the config map manifest in the target namespace:
+. Apply the `ConfigMap` manifest in the target namespace:
 +
 [source,terminal]
 ----
 $ oc apply -n <target_namespace> -f <dpdk_config_map>.yaml
 ----
 
-. Create a `Job` object to run the checkup:
+. Create a `Job` manifest to run the checkup:
 +
 .Example job manifest
 [source,yaml]
@@ -198,7 +263,7 @@ data:
   status.result.dropRate: 0
 ----
 
-. Delete the job and config map resources that you previously created by running the following commands:
+. Delete the job and config map that you previously created by running the following commands:
 +
 [source,terminal]
 ----
@@ -210,9 +275,9 @@ $ oc delete job -n <target_namespace> dpdk-checkup
 $ oc delete config-map -n <target_namespace> dpdk-checkup-config
 ----
 
-. Optional: If you do not plan to run another checkup, delete the checkup roles manifest:
+. Optional: If you do not plan to run another checkup, delete the `ServiceAccount`, `Role`, and `RoleBinding` manifest:
 +
 [source,terminal]
 ----
-$ oc delete -f <file_name>.yaml
+$ oc delete -f <dpdk_sa_roles_rolebinding>.yaml
 ----

modules/virt-measuring-latency-vm-secondary-network.adoc

@@ -4,13 +4,18 @@
 
 :_content-type: PROCEDURE
 [id="virt-measuring-latency-vm-secondary-network_{context}"]
-= Checking network connectivity and latency for virtual machines on a secondary network
+= Virtual machine latency checkup
 
-You use a predefined checkup to verify network connectivity and measure latency between two virtual machines (VMs) that are attached to a secondary network interface.
+You use a predefined checkup to verify network connectivity and measure latency between two virtual machines (VMs) that are attached to a secondary network interface. The latency checkup uses the ping utility.
 
-To run a checkup for the first time, follow the steps in the procedure.
+You run a latency checkup by performing the following steps:
 
-If you have previously run a checkup, skip to step 5 of the procedure because the steps to install the framework and enable permissions for the checkup are not required.
+. Create a service account, roles, and rolebindings to provide cluster access permissions to the latency checkup.
+. Create a config map to provide the input to run the checkup and to store the results.
+. Create a job to run the checkup.
+. Review the results in the config map.
+. Optional: To rerun the checkup, delete the existing config map and job and then create a new config map and job.
+. When you are finished, delete the latency checkup resources.
 
 .Prerequisites
 
@@ -21,7 +26,7 @@ If you have previously run a checkup, skip to step 5 of the procedure because th
 
 .Procedure
 
-. Create a manifest file that contains the `ServiceAccount`, `Role`, and `RoleBinding` objects with permissions that the checkup requires for cluster access:
+. Create a `ServiceAccount`, `Role`, and `RoleBinding` manifest for the latency checkup:
 +
 .Example role manifest file
 [%collapsible]
@@ -84,15 +89,15 @@ roleRef:
 ----
 ====
 
-. Apply the checkup roles manifest:
+. Apply the `ServiceAccount`, `Role`, and `RoleBinding` manifest:
 +
 [source,terminal]
 ----
-$ oc apply -n <target_namespace> -f <latency_roles>.yaml <1>
+$ oc apply -n <target_namespace> -f <latency_sa_roles_rolebinding>.yaml <1>
 ----
 <1> `<target_namespace>` is the namespace where the checkup is to be run. This must be an existing namespace where the `NetworkAttachmentDefinition` object resides.
 
-. Create a `ConfigMap` manifest that contains the input parameters for the checkup. The config map provides the input for the framework to run the checkup and also stores the results of the checkup.
+. Create a `ConfigMap` manifest that contains the input parameters for the checkup:
 +
 .Example input config map
 [source,yaml]
@@ -123,7 +128,7 @@ data:
 $ oc apply -n <target_namespace> -f <latency_config_map>.yaml
 ----
 
-. Create a `Job` object to run the checkup:
+. Create a `Job` manifest to run the checkup:
 +
 .Example job manifest
 [source,yaml]
@@ -155,7 +160,7 @@ spec:
               value: kubevirt-vm-latency-checkup-config
 ----
 
-. Apply the `Job` manifest. The checkup uses the ping utility to verify connectivity and measure latency.
+. Apply the `Job` manifest:
 +
 [source,terminal]
 ----
@@ -212,7 +217,7 @@ data:
 $ oc logs job.batch/kubevirt-vm-latency-checkup -n <target_namespace>
 ----
 
-. Delete the job and config map resources that you previously created by running the following commands:
+. Delete the job and config map that you previously created by running the following commands:
 +
 [source,terminal]
 ----
@@ -224,9 +229,9 @@ $ oc delete job -n <target_namespace> kubevirt-vm-latency-checkup
 $ oc delete config-map -n <target_namespace> kubevirt-vm-latency-checkup-config
 ----
 
-. Optional: If you do not plan to run another checkup, delete the checkup role and framework manifest files.
+. Optional: If you do not plan to run another checkup, delete the roles manifest:
 +
 [source,terminal]
 ----
-$ oc delete -f <file_name>.yaml
+$ oc delete -f <latency_sa_roles_rolebinding>.yaml
 ----

virt/support/monitoring/virt-monitoring-overview.adoc

@@ -9,7 +9,9 @@ toc::[]
 You can monitor the health of your cluster and virtual machines (VMs) with the following tools:
 
 xref:../../../virt/support/monitoring/virt-running-cluster-checkups.adoc#virt-running-cluster-checkups[{product-title} cluster checkup framework]::
-Check network connectivity and latency by using predefined, automated tests.
+Run automated tests on your cluster with the {product-title} cluster checkup framework to check the following conditions:
+* Network connectivity and latency between two VMs attached to a secondary network interface
+* VM running a Data Plane Development Kit (DPDK) workload with zero packet loss
 
 :FeatureName: The {product-title} cluster checkup framework
 include::snippets/technology-preview.adoc[]