diff --git a/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc b/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc index d7e287f56cc4..7f5a655474fc 100644 --- a/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc +++ b/edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc @@ -62,10 +62,7 @@ include::modules/ztp-using-pgt-to-maximize-power-saving-mode.adoc[leveloffset=+2 include::modules/ztp-provisioning-lvm-storage.adoc[leveloffset=+1] -[id="ztp-advanced-policy-config-ptp_{context}"] -== Configuring PTP events with {policy-gen-cr} CRs - -You can use the {ztp} pipeline to configure PTP events that use HTTP transport. +include::modules/ztp-about-configuring-ptp-events-with-pgt.adoc[leveloffset=+1] include::modules/ztp-configuring-ptp-fast-events.adoc[leveloffset=+2] @@ -99,4 +96,4 @@ include::modules/ztp-configuring-pgt-image-registry.adoc[leveloffset=+2] :!policy-prefix: :!rangen-yaml-path: :!argocd-folder: -:!path-prefix: \ No newline at end of file +:!path-prefix: diff --git a/modules/ztp-about-configuring-ptp-events-with-pgt.adoc b/modules/ztp-about-configuring-ptp-events-with-pgt.adoc new file mode 100644 index 000000000000..bc77d335346f --- /dev/null +++ b/modules/ztp-about-configuring-ptp-events-with-pgt.adoc @@ -0,0 +1,10 @@ +// Module included in the following assemblies: +// +// * edge_computing/policygenerator_for_ztp/ztp-advanced-policygenerator-config.adoc + +:_mod-docs-content-type: CONCEPT +[id="ztp-advanced-policy-config-ptp_{context}"] += Configuring PTP events with {policy-gen-cr} CRs + +[role="_abstract"] +You can use the {ztp} pipeline to configure PTP events that use HTTP transport. diff --git a/modules/ztp-add-local-reg-for-sno-duprofile.adoc b/modules/ztp-add-local-reg-for-sno-duprofile.adoc index 69330f59ae69..64f489cee828 100644 --- a/modules/ztp-add-local-reg-for-sno-duprofile.adoc +++ b/modules/ztp-add-local-reg-for-sno-duprofile.adoc @@ -7,6 +7,7 @@ [id="ztp-add-local-reg-for-sno-duprofile_{context}"] = Configuring the Image Registry Operator for local caching of images +[role="_abstract"] {product-title} manages image caching using a local registry. In edge computing use cases, clusters are often subject to bandwidth restrictions when communicating with centralized image registries, which might result in long image download times. Long download times are unavoidable during initial deployment. Over time, there is a risk that CRI-O will erase the `/var/lib/containers/storage` directory in the case of an unexpected shutdown. diff --git a/modules/ztp-adding-new-content-to-gitops-ztp.adoc b/modules/ztp-adding-new-content-to-gitops-ztp.adoc index 50498b828c7e..8cc802f9dfa5 100644 --- a/modules/ztp-adding-new-content-to-gitops-ztp.adoc +++ b/modules/ztp-adding-new-content-to-gitops-ztp.adoc @@ -8,6 +8,7 @@ [id="ztp-adding-new-content-to-gitops-ztp_{context}"] = Adding custom content to the {ztp} pipeline +[role="_abstract"] Perform the following procedure to add new content to the {ztp} pipeline. .Procedure @@ -16,21 +17,25 @@ Perform the following procedure to add new content to the {ztp} pipeline. . Add your user-provided CRs to the `source-crs` subdirectory, as shown in the following example: + +-- ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"] include::snippets/pgt-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc[] endif::[] ifeval::["{policy-gen-cr}" == "PolicyGenerator"] include::snippets/pg-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc[] endif::[] +-- . Update the required `{policy-gen-cr}` CRs to include references to the content you added in the `source-crs/custom-crs` and `source-crs/elasticsearch` directories. For example: + +-- ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"] include::snippets/pgt-ztp-adding-new-content-to-gitops-ztp.adoc[] endif::[] ifeval::["{policy-gen-cr}" == "PolicyGenerator"] include::snippets/pg-ztp-adding-new-content-to-gitops-ztp.adoc[] endif::[] +-- . Commit the `{policy-gen-cr}` change in Git, and then push to the Git repository that is monitored by the GitOps ZTP Argo CD policies application. @@ -70,7 +75,7 @@ $ oc apply -f cgu-test.yaml $ oc get cgu -A ---- + -.Example output +Example output: + [source, terminal] ---- diff --git a/modules/ztp-configuring-disk-partitioning.adoc b/modules/ztp-configuring-disk-partitioning.adoc index 7a9927af9c4c..a50a886f640e 100644 --- a/modules/ztp-configuring-disk-partitioning.adoc +++ b/modules/ztp-configuring-disk-partitioning.adoc @@ -7,6 +7,7 @@ [id="ztp-configuring-disk-partitioning_{context}"] = Configuring disk partitioning with ClusterInstance +[role="_abstract"] Configure disk partitioning for a managed cluster using a `ClusterInstance` CR and {ztp-first}. The disk partition details in the `ClusterInstance` CR must match the underlying disk. [IMPORTANT] @@ -28,12 +29,12 @@ variant: fcos version: 1.3.0 storage: disks: - - device: /dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0 <1> + - device: /dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0 wipe_table: false partitions: - label: var-lib-containers - start_mib: <2> - size_mib: <3> + start_mib: + size_mib: filesystems: - path: /var/lib/containers device: /dev/disk/by-partlabel/var-lib-containers @@ -44,9 +45,12 @@ storage: - defaults - prjquota ---- -<1> Specify the root disk. -<2> Specify the start of the partition in MiB. If the value is too small, the installation fails. -<3> Specify the size of the partition. If the value is too small, the deployments fails. ++ +where: + +`storage.device`:: Specifies the root disk. +`storage.disks.partitions.start_mib`:: Specifies the start of the partition in MiB. If the value is too small, the installation fails. +`storage.disks.partitions.size_mib`:: Specifies the size of the partition. If the value is too small, the deployments fails. . Convert the `storage.bu` to an Ignition file by running the following command: + @@ -56,7 +60,6 @@ storage: $ butane storage.bu ---- -.Example output [source,terminal] ---- {"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}} @@ -67,7 +70,7 @@ $ butane storage.bu . Copy the output into the `spec.nodes[].ignitionConfigOverride` field in the `ClusterInstance` CR. + -.Example +Example: [source,yaml] ---- apiVersion: siteconfig.open-cluster-management.io/v1alpha1 @@ -139,7 +142,6 @@ If the `spec.nodes[].ignitionConfigOverride` field does not exist, create it. $ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"] ---- -.Example output [source,terminal] ---- "{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}" @@ -169,7 +171,7 @@ $ oc debug node/my-sno-node # lsblk ---- + -.Example output +Example output: [source,terminal] ---- NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS @@ -193,7 +195,7 @@ sda 8:0 0 446.6G 0 disk # df -h ---- + -.Example output +Example output: [source,terminal] ---- Filesystem Size Used Avail Use% Mounted on diff --git a/modules/ztp-configuring-pgt-compliance-eval-timeouts.adoc b/modules/ztp-configuring-pgt-compliance-eval-timeouts.adoc index 37a51efbdc25..80b9aa217dde 100644 --- a/modules/ztp-configuring-pgt-compliance-eval-timeouts.adoc +++ b/modules/ztp-configuring-pgt-compliance-eval-timeouts.adoc @@ -7,6 +7,7 @@ [id="ztp-configuring-pgt-compliance-eval-timeouts_{context}"] = Configuring policy compliance evaluation timeouts for {policy-gen-cr} CRs +[role="_abstract"] Use {rh-rhacm-first} installed on a hub cluster to monitor and report on whether your managed clusters are compliant with applied policies. {rh-rhacm} uses policy templates to apply predefined policy controllers and policies. Policy controllers are Kubernetes custom resource definition (CRD) instances. You can override the default policy evaluation intervals with `{policy-gen-cr}` custom resources (CRs). You configure duration settings that define how long a `ConfigurationPolicy` CR can be in a state of policy compliance or non-compliance before {rh-rhacm} re-evaluates the applied cluster policies. @@ -87,7 +88,7 @@ Check that the managed spoke cluster policies are monitored at the expected inte $ oc get pods -n open-cluster-management-agent-addon ---- + -.Example output +Example output: [source,terminal] ---- NAME READY STATUS RESTARTS AGE @@ -101,7 +102,7 @@ config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 1 $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb ---- + -.Example output +Example output: [source,terminal] ---- 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} diff --git a/modules/ztp-configuring-pgt-image-registry.adoc b/modules/ztp-configuring-pgt-image-registry.adoc index 5209ee883e43..f8c0682f75e8 100644 --- a/modules/ztp-configuring-pgt-image-registry.adoc +++ b/modules/ztp-configuring-pgt-image-registry.adoc @@ -7,6 +7,7 @@ [id="ztp-configuring-pgt-image-registry_{context}"] = Configuring the image registry using {policy-gen-cr} CRs +[role="_abstract"] Use `{policy-gen-cr}` (PGT) CRs to apply the CRs required to configure the image registry and patch the `imageregistry` configuration. .Prerequisites @@ -32,7 +33,7 @@ sourceFiles: metadata: name: image-registry-sc annotations: - ran.openshift.io/ztp-deploy-wave: "100" <1> + ran.openshift.io/ztp-deploy-wave: "100" # persistent volume claim - fileName: StoragePVC.yaml policyName: "pvc-for-image-registry" @@ -50,7 +51,7 @@ sourceFiles: storageClassName: image-registry-sc volumeMode: Filesystem # persistent volume - - fileName: ImageRegistryPV.yaml <2> + - fileName: ImageRegistryPV.yaml policyName: "pv-for-image-registry" metadata: annotations: @@ -66,8 +67,11 @@ sourceFiles: pvc: claim: "image-registry-pvc" ---- -<1> Set the appropriate value for `ztp-deploy-wave` depending on whether you are configuring image registries at the site, common, or group level. `ztp-deploy-wave: "100"` is suitable for development or testing because it allows you to group the referenced source files together. -<2> In `ImageRegistryPV.yaml`, ensure that the `spec.local.path` field is set to `/var/imageregistry` to match the value set for the `mount_point` field in the `ClusterInstance` CR. ++ +where: + +`sourceFiles.metadata.annotations.ztp-deploy-wave`:: Specifies the appropriate value for `ztp-deploy-wave` depending on whether you are configuring image registries at the site, common, or group level. `ztp-deploy-wave: "100"` is suitable for development or testing because it allows you to group the referenced source files together. +`sourceFiles.fileName`:: In `ImageRegistryPV.yaml`, ensure that the `spec.local.path` field is set to `/var/imageregistry` to match the value set for the `mount_point` field in the `ClusterInstance` CR. + [IMPORTANT] @@ -113,7 +117,7 @@ $ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeco $ oc get image.config.openshift.io cluster -o yaml ---- + -.Example output +Example output: [source,yaml] ---- apiVersion: config.openshift.io/v1 @@ -148,7 +152,7 @@ $ oc get pv image-registry-sc $ oc get pods -n openshift-image-registry | grep registry* ---- + -.Example output +Example output: [source,terminal] ---- cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d @@ -175,8 +179,9 @@ sda 8:0 0 446.6G 0 disk |-sda2 8:2 0 127M 0 part |-sda3 8:3 0 384M 0 part /boot |-sda4 8:4 0 336.3G 0 part /sysroot - `-sda5 8:5 0 100.1G 0 part /var/imageregistry <1> + `-sda5 8:5 0 100.1G 0 part /var/imageregistry sdb 8:16 0 446.6G 0 disk sr0 11:0 1 104M 0 rom ---- -<1> `/var/imageregistry` indicates that the disk is correctly partitioned. + +`/var/imageregistry` indicates that the disk is correctly partitioned. diff --git a/modules/ztp-configuring-ptp-fast-events.adoc b/modules/ztp-configuring-ptp-fast-events.adoc index 83af157a3d74..cf4b60fdf38f 100644 --- a/modules/ztp-configuring-ptp-fast-events.adoc +++ b/modules/ztp-configuring-ptp-fast-events.adoc @@ -7,6 +7,7 @@ [id="ztp-configuring-ptp-fast-events_{context}"] = Configuring PTP events that use HTTP transport +[role="_abstract"] You can configure PTP events that use HTTP transport on managed clusters that you deploy with the {ztp-first} pipeline. .Prerequisites @@ -40,12 +41,14 @@ In {product-title} 4.13 or later, you do not need to set the `transportHost` fie .. Configure the `linuxptp` and `phc2sys` for the PTP clock type and interface. For example, add the following YAML into `{rangen-yaml-path}`: + +-- ifeval::["{policy-gen-cr}" == "PolicyGenTemplate"] include::snippets/pgt-ztp-configuring-ptp-fast-events-linuxptp.adoc[] endif::[] ifeval::["{policy-gen-cr}" == "PolicyGenerator"] include::snippets/pg-ztp-configuring-ptp-fast-events-linuxptp.adoc[] endif::[] +-- . Merge any other required changes and files with your custom site repository. diff --git a/modules/ztp-creating-a-validator-inform-policy.adoc b/modules/ztp-creating-a-validator-inform-policy.adoc index ef77ee209b60..6b85ac4d2523 100644 --- a/modules/ztp-creating-a-validator-inform-policy.adoc +++ b/modules/ztp-creating-a-validator-inform-policy.adoc @@ -7,6 +7,7 @@ [id="ztp-creating-a-validator-inform-policy_{context}"] = Signalling {ztp} cluster deployment completion with validator inform policies +[role="_abstract"] Create a validator inform policy that signals when the {ztp-first} installation and configuration of the deployed cluster is complete. This policy can be used for deployments of {sno} clusters, three-node clusters, and standard clusters. .Procedure diff --git a/modules/ztp-deploying-additional-changes-to-clusters.adoc b/modules/ztp-deploying-additional-changes-to-clusters.adoc index 06cf23da13cb..220412a63f7d 100644 --- a/modules/ztp-deploying-additional-changes-to-clusters.adoc +++ b/modules/ztp-deploying-additional-changes-to-clusters.adoc @@ -7,6 +7,7 @@ [id="ztp-deploying-additional-changes-to-clusters_{context}"] = Deploying additional changes to clusters +[role="_abstract"] If you require cluster configuration changes outside of the base {ztp-first} pipeline configuration, there are three options: Apply the additional configuration after the {ztp} pipeline is complete:: When the {ztp} pipeline deployment is complete, the deployed cluster is ready for application workloads. At this point, you can install additional Operators and apply configurations specific to your requirements. Ensure that additional configurations do not negatively affect the performance of the platform or allocated CPU budget. diff --git a/modules/ztp-provisioning-lvm-storage.adoc b/modules/ztp-provisioning-lvm-storage.adoc index 5cef2101f466..5b26c462495b 100644 --- a/modules/ztp-provisioning-lvm-storage.adoc +++ b/modules/ztp-provisioning-lvm-storage.adoc @@ -7,6 +7,7 @@ [id="ztp-provisioning-lvm-storage_{context}"] = Configuring {lvms} using {policy-gen-cr} CRs +[role="_abstract"] You can configure {lvms-first} for managed clusters that you deploy with {ztp-first}. [NOTE] diff --git a/modules/ztp-using-pgt-to-configure-high-performance-mode.adoc b/modules/ztp-using-pgt-to-configure-high-performance-mode.adoc index 930cb1934f26..24237fcd2c37 100644 --- a/modules/ztp-using-pgt-to-configure-high-performance-mode.adoc +++ b/modules/ztp-using-pgt-to-configure-high-performance-mode.adoc @@ -7,6 +7,7 @@ [id="ztp-using-pgt-to-configure-high-performance-mode_{context}"] = Configuring high-performance mode using {policy-gen-cr} CRs +[role="_abstract"] Follow this example to set high performance mode by updating the `workloadHints` fields in the generated `PerformanceProfile` CR for the reference configuration, based on the `{policy-gen-cr}` CR in the `{policy-prefix}group-du-sno-ranGen.yaml`. High performance mode provides ultra low latency at the highest power consumption. diff --git a/modules/ztp-using-pgt-to-configure-performance-mode.adoc b/modules/ztp-using-pgt-to-configure-performance-mode.adoc index 1de5350d7621..114cb7a3fb85 100644 --- a/modules/ztp-using-pgt-to-configure-performance-mode.adoc +++ b/modules/ztp-using-pgt-to-configure-performance-mode.adoc @@ -7,6 +7,7 @@ [id="ztp-using-pgt-to-configure-performance-mode_{context}"] = Configuring performance mode using {policy-gen-cr} CRs +[role="_abstract"] Follow this example to set performance mode by updating the `workloadHints` fields in the generated `PerformanceProfile` CR for the reference configuration, based on the `{policy-gen-cr}` CR in the `{policy-prefix}group-du-sno-ranGen.yaml`. Performance mode provides low latency at a relatively high power consumption. diff --git a/modules/ztp-using-pgt-to-configure-power-saving-mode.adoc b/modules/ztp-using-pgt-to-configure-power-saving-mode.adoc index 9fad0d0556bf..0820a35569ba 100644 --- a/modules/ztp-using-pgt-to-configure-power-saving-mode.adoc +++ b/modules/ztp-using-pgt-to-configure-power-saving-mode.adoc @@ -7,6 +7,7 @@ [id="ztp-using-pgt-to-configure-power-saving-mode_{context}"] = Configuring power saving mode using {policy-gen-cr} CRs +[role="_abstract"] Follow this example to set power saving mode by updating the `workloadHints` fields in the generated `PerformanceProfile` CR for the reference configuration, based on the `{policy-gen-cr}` CR in the `{policy-prefix}group-du-sno-ranGen.yaml`. The power saving mode balances reduced power consumption with increased latency. @@ -60,6 +61,5 @@ Replace `` with the name of the node you want to verify the power sta # cat /proc/cmdline ---- -.Expected output * For power saving mode the `intel_pstate=passive`. diff --git a/modules/ztp-using-pgt-to-configure-power-states.adoc b/modules/ztp-using-pgt-to-configure-power-states.adoc index 757dac01ad47..2b76d176e1fc 100644 --- a/modules/ztp-using-pgt-to-configure-power-states.adoc +++ b/modules/ztp-using-pgt-to-configure-power-states.adoc @@ -7,7 +7,9 @@ [id="ztp-using-pgt-to-configure-power-saving-states_{context}"] = Configuring power states using {policy-gen-cr} CRs +[role="_abstract"] For low latency and high-performance edge deployments, it is necessary to disable or limit C-states and P-states. + With this configuration, the CPU runs at a constant frequency, which is typically the maximum turbo frequency. This ensures that the CPU is always running at its maximum speed, which results in high performance and low latency. This leads to the best latency for workloads. However, this also leads to the highest power consumption, which might not be necessary for all workloads. @@ -24,9 +26,7 @@ The default configuration is for a low latency, performance mode. Configure the power states by updating the `workloadHints` fields in the generated `PerformanceProfile` CR for the reference configuration, based on the `{policy-gen-cr}` CR in the `{policy-prefix}group-du-sno-ranGen.yaml`. -The following common prerequisites apply to configuring all three power states. - -.Prerequisites +The following common prerequisites apply to configuring all three power states: * You have created a Git repository where you manage your custom site configuration data. The repository must be accessible from the hub cluster and be defined as a source repository for Argo CD. diff --git a/modules/ztp-using-pgt-to-maximize-power-saving-mode.adoc b/modules/ztp-using-pgt-to-maximize-power-saving-mode.adoc index a9c86eaf297a..d2d529c141b3 100644 --- a/modules/ztp-using-pgt-to-maximize-power-saving-mode.adoc +++ b/modules/ztp-using-pgt-to-maximize-power-saving-mode.adoc @@ -7,7 +7,9 @@ [id="ztp-using-pgt-to-maximize-power-savings-mode_{context}"] = Maximizing power savings +[role="_abstract"] Limiting the maximum CPU frequency is recommended to achieve maximum power savings. + Enabling C-states on the non-critical workload CPUs without restricting the maximum CPU frequency negates much of the power savings by boosting the frequency of the critical CPUs. Maximize power savings by updating the `sysfs` plugin fields, setting an appropriate value for `max_perf_pct` in the `TunedPerformancePatch` CR for the reference configuration. This example based on the `{policy-prefix}group-du-sno-ranGen.yaml` describes the procedure to follow to restrict the maximum CPU frequency. diff --git a/modules/ztp-using-pgt-to-update-source-crs.adoc b/modules/ztp-using-pgt-to-update-source-crs.adoc index 221390030bc7..4da8c630dd7e 100644 --- a/modules/ztp-using-pgt-to-update-source-crs.adoc +++ b/modules/ztp-using-pgt-to-update-source-crs.adoc @@ -7,6 +7,7 @@ [id="ztp-using-pgt-to-update-source-crs_{context}"] = Using {policy-gen-cr} CRs to override source CRs content +[role="_abstract"] `{policy-gen-cr}` custom resources (CRs) allow you to overlay additional configuration details on top of the base source CRs provided with the GitOps plugin in the `ztp-site-generate` container. You can think of `{policy-gen-cr}` CRs as a logical merge or patch to the base CR. Use `{policy-gen-cr}` CRs to update a single field of the base CR, or overlay the entire contents of the base CR. You can update values and insert fields that are not in the base CR. The following example procedure describes how to update fields in the generated `PerformanceProfile` CR for the reference configuration based on the `{policy-gen-cr}` CR in the `{policy-prefix}group-du-sno-ranGen.yaml` file. Use the procedure as a basis for modifying other parts of the `{policy-gen-cr}` based on your requirements. @@ -87,7 +88,7 @@ endif::[] . Commit the `{policy-gen-cr}` change in Git, and then push to the Git repository being monitored by the {ztp} argo CD application. + -.Example output +Example output: The {ztp} application generates an {rh-rhacm} policy that contains the generated `PerformanceProfile` CR. The contents of that CR are derived by merging the `metadata` and `spec` contents from the `PerformanceProfile` entry in the `{policy-gen-cr}` onto the source CR. The resulting CR has the following content: + [source,yaml] @@ -121,6 +122,7 @@ spec: realTimeKernel: enabled: true ---- ++ [NOTE] ==== diff --git a/snippets/pg-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc b/snippets/pg-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc index da3df80a080b..0e903c57e40b 100644 --- a/snippets/pg-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc +++ b/snippets/pg-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc @@ -7,7 +7,7 @@ example ├── kustomization.yaml ├── mec-edge-sno1.yaml ├── sno.yaml - └── source-crs <1> + └── source-crs ├── PaoCatalogSource.yaml ├── PaoSubscription.yaml ├── custom-crs @@ -17,4 +17,5 @@ example ├── ElasticsearchNS.yaml └── ElasticsearchOperatorGroup.yaml ---- -<1> The `source-crs` subdirectory must be in the same directory as the `kustomization.yaml` file. + +The `source-crs` subdirectory must be in the same directory as the `kustomization.yaml` file. diff --git a/snippets/pg-ztp-adding-new-content-to-gitops-ztp.adoc b/snippets/pg-ztp-adding-new-content-to-gitops-ztp.adoc index 7dd94da67b88..86a75879e02c 100644 --- a/snippets/pg-ztp-adding-new-content-to-gitops-ztp.adoc +++ b/snippets/pg-ztp-adding-new-content-to-gitops-ztp.adoc @@ -79,7 +79,7 @@ policies: policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - - path: elasticsearch/ElasticsearchNS.yaml <1> + - path: elasticsearch/ElasticsearchNS.yaml - name: group-dev-group-dev-elasticsearch-operator-group policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" @@ -89,11 +89,12 @@ policies: policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - - path: custom-crs/apiserver-config.yaml <1> + - path: custom-crs/apiserver-config.yaml - name: group-dev-group-dev-disable-nic-lldp policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: custom-crs/disable-nic-lldp.yaml ---- -<1> Set `policies.manifests.path` to include the relative path to the file from the `/source-crs` parent directory. + +Set `policies.manifests.path` to include the relative path to the file from the `/source-crs` parent directory. diff --git a/snippets/pg-ztp-configuring-ptp-fast-events-linuxptp.adoc b/snippets/pg-ztp-configuring-ptp-fast-events-linuxptp.adoc index a49a065c5ce8..d0cec8047700 100644 --- a/snippets/pg-ztp-configuring-ptp-fast-events-linuxptp.adoc +++ b/snippets/pg-ztp-configuring-ptp-fast-events-linuxptp.adoc @@ -1,7 +1,7 @@ :_mod-docs-content-type: SNIPPET [source,yaml] ---- -- path: source-crs/PtpConfigSlave.yaml <1> +- path: source-crs/PtpConfigSlave.yaml patches: - metadata: name: "du-ptp-slave" @@ -14,9 +14,9 @@ profile: - name: "slave" # This interface must match the hardware in this group - interface: "ens5f0" <2> - ptp4lOpts: "-2 -s --summary_interval -4" <3> - phc2sysOpts: "-a -r -n 24" <4> + interface: "ens5f0" + ptp4lOpts: "-2 -s --summary_interval -4" + phc2sysOpts: "-a -r -n 24" ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: @@ -123,13 +123,17 @@ manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 - ptpClockThreshold: <5> + ptpClockThreshold: holdOverTimeout: 30 # seconds maxOffsetThreshold: 100 # nano seconds minOffsetThreshold: -100 ---- -<1> Can be `PtpConfigMaster.yaml` or `PtpConfigSlave.yaml` depending on your requirements. For configurations based on `{policy-prefix}group-du-sno-ranGen.yaml` or `{policy-prefix}group-du-3node-ranGen.yaml`, use `PtpConfigSlave.yaml`. -<2> Device specific interface name. -<3> You must append the `--summary_interval -4` value to `ptp4lOpts` in `.spec.sourceFiles.spec.profile` to enable PTP fast events. -<4> Required `phc2sysOpts` values. `-m` prints messages to `stdout`. The `linuxptp-daemon` `DaemonSet` parses the logs and generates Prometheus metrics. -<5> Optional. If the `ptpClockThreshold` stanza is not present, default values are used for the `ptpClockThreshold` fields. The stanza shows default `ptpClockThreshold` values. The `ptpClockThreshold` values configure how long after the PTP master clock is disconnected before PTP events are triggered. `holdOverTimeout` is the time value in seconds before the PTP clock event state changes to `FREERUN` when the PTP master clock is disconnected. The `maxOffsetThreshold` and `minOffsetThreshold` settings configure offset values in nanoseconds that compare against the values for `CLOCK_REALTIME` (`phc2sys`) or master offset (`ptp4l`). When the `ptp4l` or `phc2sys` offset value is outside this range, the PTP clock state is set to `FREERUN`. When the offset value is within this range, the PTP clock state is set to `LOCKED`. + +where: + +`path`:: Specifies `PtpConfigMaster.yaml` or `PtpConfigSlave.yaml` depending on your requirements. For configurations based on `{policy-prefix}group-du-sno-ranGen.yaml` or `{policy-prefix}group-du-3node-ranGen.yaml`, use `PtpConfigSlave.yaml`. +`patches.spec.profile.interface`:: Specifies the device specific interface name. +`patches.spec.profile.ptp4lOpts`:: Specifies the ptp4l options. You must append the `--summary_interval -4` value to `ptp4lOpts` in `.spec.sourceFiles.spec.profile` to enable PTP fast events. +`patches.spec.profile.phc2sysOpts`:: Specifies the required `phc2sysOpts` values. `-m` prints messages to `stdout`. The `linuxptp-daemon` `DaemonSet` parses the logs and generates Prometheus metrics. +`patches.spec.ptpClockThreshold`:: Specifies the PTP clock threshold settings. Optional. If the `ptpClockThreshold` stanza is not present, default values are used for the `ptpClockThreshold` fields. The stanza shows default `ptpClockThreshold` values. The `ptpClockThreshold` values configure how long after the PTP master clock is disconnected before PTP events are triggered. `holdOverTimeout` is the time value in seconds before the PTP clock event state changes to `FREERUN` when the PTP master clock is disconnected. The `maxOffsetThreshold` and `minOffsetThreshold` settings configure offset values in nanoseconds that compare against the values for `CLOCK_REALTIME` (`phc2sys`) or master offset (`ptp4l`). When the `ptp4l` or `phc2sys` offset value is outside this range, the PTP clock state is set to `FREERUN`. When the offset value is within this range, the PTP clock state is set to `LOCKED`. + diff --git a/snippets/pg-ztp-example-single-node-cluster-validator.adoc b/snippets/pg-ztp-example-single-node-cluster-validator.adoc index efd43e7f010f..b588375efc6a 100644 --- a/snippets/pg-ztp-example-single-node-cluster-validator.adoc +++ b/snippets/pg-ztp-example-single-node-cluster-validator.adoc @@ -1,4 +1,6 @@ -.Example single-node cluster validator inform policy CR (acm-group-du-sno-validator-ranGen.yaml) +:_mod-docs-content-type: SNIPPET +Example single-node cluster validator inform policy CR (acm-group-du-sno-validator-ranGen.yaml): ++ [source,yaml] ---- apiVersion: policy.open-cluster-management.io/v1 diff --git a/snippets/pg-ztp-using-pg-to-configure-high-performance-mode.yaml b/snippets/pg-ztp-using-pg-to-configure-high-performance-mode.yaml index 25c48381f62a..f84af176ffa3 100644 --- a/snippets/pg-ztp-using-pg-to-configure-high-performance-mode.yaml +++ b/snippets/pg-ztp-using-pg-to-configure-high-performance-mode.yaml @@ -4,4 +4,4 @@ workloadHints: realTime: true highPowerConsumption: true - perPodPowerManagement: false \ No newline at end of file + perPodPowerManagement: false diff --git a/snippets/pg-ztp-using-pg-to-configure-performance-mode.yaml b/snippets/pg-ztp-using-pg-to-configure-performance-mode.yaml index e50ebfac520a..593f7922f1a0 100644 --- a/snippets/pg-ztp-using-pg-to-configure-performance-mode.yaml +++ b/snippets/pg-ztp-using-pg-to-configure-performance-mode.yaml @@ -4,4 +4,4 @@ workloadHints: realTime: true highPowerConsumption: false - perPodPowerManagement: false \ No newline at end of file + perPodPowerManagement: false diff --git a/snippets/pg-ztp-using-pg-to-configure-power-saving-mode.adoc b/snippets/pg-ztp-using-pg-to-configure-power-saving-mode.adoc index 73f527fec1ce..9adb546a073b 100644 --- a/snippets/pg-ztp-using-pg-to-configure-power-saving-mode.adoc +++ b/snippets/pg-ztp-using-pg-to-configure-power-saving-mode.adoc @@ -12,6 +12,7 @@ # ... additionalKernelArgs: - # ... - - "cpufreq.default_governor=schedutil" <1> + - "cpufreq.default_governor=schedutil" ---- -<1> The `schedutil` governor is recommended, however, you can also use other governors, including `ondemand` and `powersave`. + +The `schedutil` governor is recommended, however, you can also use other governors, including `ondemand` and `powersave`. diff --git a/snippets/pg-ztp-using-pg-to-maximize-power-saving-mode.adoc b/snippets/pg-ztp-using-pg-to-maximize-power-saving-mode.adoc index c65ef14c9205..d061c80f3c3a 100644 --- a/snippets/pg-ztp-using-pg-to-maximize-power-saving-mode.adoc +++ b/snippets/pg-ztp-using-pg-to-maximize-power-saving-mode.adoc @@ -9,6 +9,7 @@ data: | # ... [sysfs] - /sys/devices/system/cpu/intel_pstate/max_perf_pct= <1> + /sys/devices/system/cpu/intel_pstate/max_perf_pct= ---- -<1> The `max_perf_pct` controls the maximum frequency the `cpufreq` driver is allowed to set as a percentage of the maximum supported CPU frequency. This value applies to all CPUs. You can check the maximum supported frequency in `/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq`. As a starting point, you can use a percentage that caps all CPUs at the `All Cores Turbo` frequency. The `All Cores Turbo` frequency is the frequency that all cores run at when the cores are all fully occupied. + +The `max_perf_pct` controls the maximum frequency the `cpufreq` driver is allowed to set as a percentage of the maximum supported CPU frequency. This value applies to all CPUs. You can check the maximum supported frequency in `/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq`. As a starting point, you can use a percentage that caps all CPUs at the `All Cores Turbo` frequency. The `All Cores Turbo` frequency is the frequency that all cores run at when the cores are all fully occupied. diff --git a/snippets/pgt-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc b/snippets/pgt-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc index 755defb2ceb4..5b6e5d0e6c89 100644 --- a/snippets/pgt-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc +++ b/snippets/pgt-ztp-adding-new-content-to-gitops-ztp-folder-structure.adoc @@ -7,7 +7,7 @@ example ├── kustomization.yaml ├── mec-edge-sno1.yaml ├── sno.yaml - └── source-crs <1> + └── source-crs ├── PaoCatalogSource.yaml ├── PaoSubscription.yaml ├── custom-crs @@ -17,4 +17,5 @@ example ├── ElasticsearchNS.yaml └── ElasticsearchOperatorGroup.yaml ---- -<1> The `source-crs` subdirectory must be in the same directory as the `kustomization.yaml` file. + +The `source-crs` subdirectory must be in the same directory as the `kustomization.yaml` file. diff --git a/snippets/pgt-ztp-adding-new-content-to-gitops-ztp.adoc b/snippets/pgt-ztp-adding-new-content-to-gitops-ztp.adoc index ab94ba18b3e9..c5a669c65532 100644 --- a/snippets/pgt-ztp-adding-new-content-to-gitops-ztp.adoc +++ b/snippets/pgt-ztp-adding-new-content-to-gitops-ztp.adoc @@ -46,18 +46,19 @@ spec: remediationAction: inform policyName: "group-dev-pao-sub" #Elasticsearch Operator - - fileName: elasticsearch/ElasticsearchNS.yaml <1> + - fileName: elasticsearch/ElasticsearchNS.yaml remediationAction: inform policyName: "group-dev-elasticsearch-ns" - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml remediationAction: inform policyName: "group-dev-elasticsearch-operator-group" #Custom Resources - - fileName: custom-crs/apiserver-config.yaml <1> + - fileName: custom-crs/apiserver-config.yaml remediationAction: inform policyName: "group-dev-apiserver-config" - fileName: custom-crs/disable-nic-lldp.yaml remediationAction: inform policyName: "group-dev-disable-nic-lldp" ---- -<1> Set `fileName` to include the relative path to the file from the `/source-crs` parent directory. + +Set `fileName` to include the relative path to the file from the `/source-crs` parent directory. diff --git a/snippets/pgt-ztp-configuring-ptp-fast-events-linuxptp.adoc b/snippets/pgt-ztp-configuring-ptp-fast-events-linuxptp.adoc index b613e2509e4d..6c0f2e366295 100644 --- a/snippets/pgt-ztp-configuring-ptp-fast-events-linuxptp.adoc +++ b/snippets/pgt-ztp-configuring-ptp-fast-events-linuxptp.adoc @@ -1,23 +1,27 @@ :_mod-docs-content-type: SNIPPET [source,yaml] ---- -- fileName: PtpConfigSlave.yaml <1> +- fileName: PtpConfigSlave.yaml policyName: "config-policy" metadata: name: "du-ptp-slave" spec: profile: - name: "slave" - interface: "ens5f1" <2> - ptp4lOpts: "-2 -s --summary_interval -4" <3> - phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" <4> - ptpClockThreshold: <5> + interface: "ens5f1" + ptp4lOpts: "-2 -s --summary_interval -4" + phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" + ptpClockThreshold: holdOverTimeout: 30 # seconds maxOffsetThreshold: 100 # nano seconds minOffsetThreshold: -100 ---- -<1> Can be `PtpConfigMaster.yaml` or `PtpConfigSlave.yaml` depending on your requirements. For configurations based on `{policy-prefix}group-du-sno-ranGen.yaml` or `{policy-prefix}group-du-3node-ranGen.yaml`, use `PtpConfigSlave.yaml`. -<2> Device specific interface name. -<3> You must append the `--summary_interval -4` value to `ptp4lOpts` in `.spec.sourceFiles.spec.profile` to enable PTP fast events. -<4> Required `phc2sysOpts` values. `-m` prints messages to `stdout`. The `linuxptp-daemon` `DaemonSet` parses the logs and generates Prometheus metrics. -<5> Optional. If the `ptpClockThreshold` stanza is not present, default values are used for the `ptpClockThreshold` fields. The stanza shows default `ptpClockThreshold` values. The `ptpClockThreshold` values configure how long after the PTP master clock is disconnected before PTP events are triggered. `holdOverTimeout` is the time value in seconds before the PTP clock event state changes to `FREERUN` when the PTP master clock is disconnected. The `maxOffsetThreshold` and `minOffsetThreshold` settings configure offset values in nanoseconds that compare against the values for `CLOCK_REALTIME` (`phc2sys`) or master offset (`ptp4l`). When the `ptp4l` or `phc2sys` offset value is outside this range, the PTP clock state is set to `FREERUN`. When the offset value is within this range, the PTP clock state is set to `LOCKED`. + +where: + +`fileName`:: Specifies `PtpConfigMaster.yaml` or `PtpConfigSlave.yaml` depending on your requirements. For configurations based on `{policy-prefix}group-du-sno-ranGen.yaml` or `{policy-prefix}group-du-3node-ranGen.yaml`, use `PtpConfigSlave.yaml`. +`spec.profile.interface`:: Specifies the device specific interface name. +`spec.profile.ptp4lOpts`:: Specifies the ptp4l options. You must append the `--summary_interval -4` value to `ptp4lOpts` in `.spec.sourceFiles.spec.profile` to enable PTP fast events. +`spec.profile.phc2sysOpts`:: Specifies the required `phc2sysOpts` values. `-m` prints messages to `stdout`. The `linuxptp-daemon` `DaemonSet` parses the logs and generates Prometheus metrics. +`spec.ptpClockThreshold`:: Specifies the PTP clock threshold settings. Optional. If the `ptpClockThreshold` stanza is not present, default values are used for the `ptpClockThreshold` fields. The stanza shows default `ptpClockThreshold` values. The `ptpClockThreshold` values configure how long after the PTP master clock is disconnected before PTP events are triggered. `holdOverTimeout` is the time value in seconds before the PTP clock event state changes to `FREERUN` when the PTP master clock is disconnected. The `maxOffsetThreshold` and `minOffsetThreshold` settings configure offset values in nanoseconds that compare against the values for `CLOCK_REALTIME` (`phc2sys`) or master offset (`ptp4l`). When the `ptp4l` or `phc2sys` offset value is outside this range, the PTP clock state is set to `FREERUN`. When the offset value is within this range, the PTP clock state is set to `LOCKED`. + diff --git a/snippets/pgt-ztp-example-single-node-cluster-validator.adoc b/snippets/pgt-ztp-example-single-node-cluster-validator.adoc index 526710bc5281..b36f317540cd 100644 --- a/snippets/pgt-ztp-example-single-node-cluster-validator.adoc +++ b/snippets/pgt-ztp-example-single-node-cluster-validator.adoc @@ -1,23 +1,26 @@ -.Example single-node cluster validator inform policy CR (group-du-sno-validator-ranGen.yaml) +:_mod-docs-content-type: SNIPPET +Example single-node cluster validator inform policy CR (group-du-sno-validator-ranGen.yaml): ++ [source,yaml] ---- apiVersion: ran.openshift.io/v1 kind: PolicyGenTemplate metadata: - name: "group-du-sno-validator" <1> - namespace: "ztp-group" <2> + name: "group-du-sno-validator" + namespace: "ztp-group" spec: bindingRules: - group-du-sno: "" <3> + group-du-sno: "" bindingExcludedRules: - ztp-done: "" <4> - mcp: "master" <5> + ztp-done: "" + mcp: "master" sourceFiles: - fileName: validatorCRs/informDuValidator.yaml - remediationAction: inform <6> - policyName: "du-policy" <7> + remediationAction: inform + policyName: "du-policy" ---- -<1> The name of the `{policy-gen-crs}` object. This name is also used as part of the names + +The name of the `{policy-gen-crs}` object. This name is also used as part of the names for the `placementBinding`, `placementRule`, and `policy` that are created in the requested `namespace`. <2> This value should match the `namespace` used in the group `policy-gen-crs`. <3> The `group-du-*` label defined in `bindingRules` must exist in the `ClusterInstance` files. diff --git a/snippets/pgt-ztp-provisioning-lvm-storage-sub.yaml b/snippets/pgt-ztp-provisioning-lvm-storage-sub.yaml index aca70a7cfeff..26b802cc6e95 100644 --- a/snippets/pgt-ztp-provisioning-lvm-storage-sub.yaml +++ b/snippets/pgt-ztp-provisioning-lvm-storage-sub.yaml @@ -3,4 +3,4 @@ - fileName: StorageLVMSubscriptionOperGroup.yaml policyName: subscription-policies - fileName: StorageLVMSubscription.yaml - policyName: subscription-policies \ No newline at end of file + policyName: subscription-policies diff --git a/snippets/pgt-ztp-using-pgt-to-configure-power-saving-mode.adoc b/snippets/pgt-ztp-using-pgt-to-configure-power-saving-mode.adoc index 0e33606979a2..edc078f475ef 100644 --- a/snippets/pgt-ztp-using-pgt-to-configure-power-saving-mode.adoc +++ b/snippets/pgt-ztp-using-pgt-to-configure-power-saving-mode.adoc @@ -14,6 +14,7 @@ # ... additionalKernelArgs: - # ... - - "cpufreq.default_governor=schedutil" <1> + - "cpufreq.default_governor=schedutil" ---- -<1> The `schedutil` governor is recommended, however, other governors that can be used include `ondemand` and `powersave`. + +The `schedutil` governor is recommended, however, other governors that can be used include `ondemand` and `powersave`. diff --git a/snippets/pgt-ztp-using-pgt-to-maximize-power-saving-mode.adoc b/snippets/pgt-ztp-using-pgt-to-maximize-power-saving-mode.adoc index 34bedf22905e..ab9832425295 100644 --- a/snippets/pgt-ztp-using-pgt-to-maximize-power-saving-mode.adoc +++ b/snippets/pgt-ztp-using-pgt-to-maximize-power-saving-mode.adoc @@ -9,6 +9,7 @@ data: | # ... [sysfs] - /sys/devices/system/cpu/intel_pstate/max_perf_pct= <1> + /sys/devices/system/cpu/intel_pstate/max_perf_pct= ---- -<1> The `max_perf_pct` controls the maximum frequency the `cpufreq` driver is allowed to set as a percentage of the maximum supported CPU frequency. This value applies to all CPUs. You can check the maximum supported frequency in `/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq`. As a starting point, you can use a percentage that caps all CPUs at the `All Cores Turbo` frequency. The `All Cores Turbo` frequency is the frequency that all cores will run at when the cores are all fully occupied. + +The `max_perf_pct` controls the maximum frequency the `cpufreq` driver is allowed to set as a percentage of the maximum supported CPU frequency. This value applies to all CPUs. You can check the maximum supported frequency in `/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq`. As a starting point, you can use a percentage that caps all CPUs at the `All Cores Turbo` frequency. The `All Cores Turbo` frequency is the frequency that all cores will run at when the cores are all fully occupied.