diff --git a/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc b/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc index b1f2571561..30b84c6480 100644 --- a/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc +++ b/edge_computing/day_2_core_cnf_clusters/observability/telco-observability.adoc @@ -7,9 +7,9 @@ include::_attributes/common-attributes.adoc[] toc::[] -{product-title} generates a large amount of data, such as performance metrics and logs from both the platform and the the workloads running on it. -As an administrator, you can use various tools to collect and analyze all the data available. -What follows is an outline of best practices for system engineers, architects, and administrators configuring the observability stack. +{product-title} generates a large amount of data, such as performance metrics and logs from both the platform and the workloads running on it. +As an administrator, you can use various tools to collect and analyze all the data available. +What follows is an outline of best practices for system engineers, architects, and administrators configuring the observability stack. Unless explicitly stated, the material in this document refers to both Edge and Core deployments. @@ -49,4 +49,4 @@ include::modules/telco-observability-workload-monitoring.adoc[leveloffset=+1] * xref:../../../observability/monitoring/enabling-monitoring-for-user-defined-projects.adoc#enabling-monitoring-for-user-defined-projects[Enabling monitoring for user-defined projects] -* xref:../../../observability/monitoring/managing-alerts.adoc#managing-alerting-rules-for-user-defined-projects_managing-alerts[Managing alerting rules for user-defined projects] \ No newline at end of file +* xref:../../../observability/monitoring/managing-alerts.adoc#managing-alerting-rules-for-user-defined-projects_managing-alerts[Managing alerting rules for user-defined projects] diff --git a/modules/ibi-create-config-iso.adoc b/modules/ibi-create-config-iso.adoc index 9594760e8c..67e5b2c6b4 100644 --- a/modules/ibi-create-config-iso.adoc +++ b/modules/ibi-create-config-iso.adoc @@ -1,12 +1,12 @@ // Module included in the following assemblies: // -// * edge_computing/ibi-edge-image-based-install.adoc +// * edge_computing/ibi-edge-image-based-install.adoc :_mod-docs-content-type: PROCEDURE [id="ibi-create-config-iso_{context}"] = Deploying a managed {sno} cluster using the IBI Operator -Create the site-specific configuration resources in the hub cluster to initiate the image-based deployment of a preinstalled host. +Create the site-specific configuration resources in the hub cluster to initiate the image-based deployment of a preinstalled host. When you create these configuration resources in the hub cluster, the Image Based Install (IBI) Operator generates a configuration ISO and attaches it to the target host to begin the site-specific configuration process. When the configuration process completes, the {sno} cluster is ready. @@ -64,7 +64,7 @@ $ oc create -f secret-image-registry.yaml .Example `host-network-config-secret.yaml` file [source,yaml] ---- -apiVersion: v1 +apiVersion: v1 kind: Secret metadata: name: host-network-config-secret <1> @@ -137,7 +137,7 @@ data: password: <11> ---- <1> Specify the name for the `BareMetalHost` resource. -<2> Specify if the host should be online. +<2> Specify if the host should be online. <3> Specify the host boot MAC address. <4> Specify the BMC address. You can only use bare-metal host drivers that support virtual media networking booting, for example redfish-virtualmedia and idrac-virtualmedia. <5> Specify the name of the bare-metal host `Secret` resource. @@ -245,7 +245,7 @@ spec: baseDomain: example.com <3> clusterInstallRef: group: extensions.hive.openshift.io - kind: ImageClusterInstall + kind: ImageClusterInstall name: ibi-image-install <4> version: v1alpha1 clusterName: ibi-cluster <5> @@ -283,7 +283,7 @@ spec: hubAcceptsClient: true <2> ---- <1> Specify the name for the `ManagedCluster` resource. -<2> Specify `true` to enable {rh-rhacm} to mange the cluster. +<2> Specify `true` to enable {rh-rhacm} to manage the cluster. .. Create the `ManagedCluster` resource by running the following command: + diff --git a/modules/microshift-automation-example-bootc-systems.adoc b/modules/microshift-automation-example-bootc-systems.adoc index 082ca88a10..302cf4e099 100644 --- a/modules/microshift-automation-example-bootc-systems.adoc +++ b/modules/microshift-automation-example-bootc-systems.adoc @@ -15,8 +15,8 @@ As a use case, consider the following example situation in which you want to aut .Prerequisites -* You have created the `10-auto-recovery.conf` and `microshift-auto-recovery.service` files as explained in the the "Automating the integration process with systemd for RPM systems" section. -* You have created the `microshift-auto-recovery` script as explained in the the "Automating the integration process with systemd for RPM systems" section. +* You have created the `10-auto-recovery.conf` and `microshift-auto-recovery.service` files as explained in the "Automating the integration process with systemd for RPM systems" section. +* You have created the `microshift-auto-recovery` script as explained in the "Automating the integration process with systemd for RPM systems" section. .Procedure diff --git a/modules/microshift-ingress-controller-config.adoc b/modules/microshift-ingress-controller-config.adoc index 98c718a426..7dd129de5c 100644 --- a/modules/microshift-ingress-controller-config.adoc +++ b/modules/microshift-ingress-controller-config.adoc @@ -22,7 +22,7 @@ You can use detailed ingress control settings by updating the {microshift-short} .. Update the {microshift-short} `config.yaml` configuration file by making a copy of the provided `config.yaml.default` file in the `/etc/microshift/` directory, naming it `config.yaml` and keeping it in the source directory. * After you create it, the `config.yaml` file takes precedence over built-in settings. The configuration file is read every time the {microshift-short} service starts. -.. Use a configuration snippet to apply the ingress control settings you want. To do this, create a configuration snippet YAML file and put it in the the `/etc/microshift/config.d/` configuration directory. +.. Use a configuration snippet to apply the ingress control settings you want. To do this, create a configuration snippet YAML file and put it in the `/etc/microshift/config.d/` configuration directory. * Configuration snippet YAMLs take precedence over both built-in settings and a `config.yaml` configuration file. See the Additional resources links for more information. . Replace the default values in the `network` section of the {microshift-short} YAML with your valid values, or create a configuration snippet file with the sections you need. @@ -164,4 +164,4 @@ $ oc get pods -n openshift-ingress ---- NAME READY STATUS RESTARTS AGE router-default-8649b5bf65-w29cn 1/1 Running 0 6m10s ----- \ No newline at end of file +---- diff --git a/modules/network-observability-multitenancy.adoc b/modules/network-observability-multitenancy.adoc index 298c2e43c6..eebd146c77 100644 --- a/modules/network-observability-multitenancy.adoc +++ b/modules/network-observability-multitenancy.adoc @@ -5,7 +5,7 @@ :_mod-docs-content-type: PROCEDURE [id="network-observability-multi-tenancy_{context}"] = Enabling multi-tenancy in Network Observability -Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki and or or Prometheus. Access is enabled for project administrators. Project administrators who have limited access to some namespaces can access flows for only those namespaces. +Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki and or Prometheus. Access is enabled for project administrators. Project administrators who have limited access to some namespaces can access flows for only those namespaces. For Developers, multi-tenancy is available for both Loki and Prometheus but requires different access rights. @@ -42,4 +42,4 @@ $ oc adm policy add-cluster-role-to-user cluster-monitoring-view ----- \ No newline at end of file +---- diff --git a/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc b/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc index 42d42b0cb5..24800dd49a 100644 --- a/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc +++ b/modules/nodes-vsphere-machine-set-scaling-static-ip.adoc @@ -94,7 +94,7 @@ Or: $ oc edit machineset -n openshift-machine-api ---- + -After each machine is scaled up, the machine controller creates an `IPAddresssClaim` resource. +After each machine is scaled up, the machine controller creates an `IPAddressClaim` resource. . Optional: Check that the `IPAddressClaim` resource exists in the `openshift-machine-api` namespace by entering the following command: + diff --git a/modules/nw-bpfman-operator-deploy.adoc b/modules/nw-bpfman-operator-deploy.adoc index 624c2c0e5f..06ae8655d6 100644 --- a/modules/nw-bpfman-operator-deploy.adoc +++ b/modules/nw-bpfman-operator-deploy.adoc @@ -82,7 +82,7 @@ go-xdp-counter-example xdp_stats {} ReconcileSuccess $ oc logs -n go-xdp-counter ---- + -Replace `` with the name of a XDP program pod, such as `go-xdp-counter-ds-4m9cw`. +Replace `` with the name of an XDP program pod, such as `go-xdp-counter-ds-4m9cw`. + .Example output [source,text] diff --git a/modules/nw-external-dns-operator-configuration-parameters.adoc b/modules/nw-external-dns-operator-configuration-parameters.adoc index 4f286b6625..c7be49f55a 100644 --- a/modules/nw-external-dns-operator-configuration-parameters.adoc +++ b/modules/nw-external-dns-operator-configuration-parameters.adoc @@ -52,7 +52,7 @@ domains: pattern: ".*\\.otherzonedomain\\.com" <5> ---- <1> Ensures that the `ExternalDNS` resource includes the domain name. -<2> Instructs `ExtrnalDNS` that the domain matching has to be exact as opposed to regular expression match. +<2> Instructs `ExternalDNS` that the domain matching has to be exact as opposed to regular expression match. <3> Defines the name of the domain. <4> Sets the `regex-domain-filter` flag in the `ExternalDNS` resource. You can limit possible domains by using a Regex filter. <5> Defines the regex pattern to be used by the `ExternalDNS` resource to filter the domains of the target zones. diff --git a/modules/nw-sriov-networknodepolicy-object.adoc b/modules/nw-sriov-networknodepolicy-object.adoc index 1bccc5ba1f..78cc2fc2c4 100644 --- a/modules/nw-sriov-networknodepolicy-object.adoc +++ b/modules/nw-sriov-networknodepolicy-object.adoc @@ -67,7 +67,7 @@ To avoid a node in an unhealthy MCP from blocking the application of node networ + [NOTE] ==== -When `externallyManaged` is set to `true`, you must manually create the Virtual Functions (VFs) on the physical function (PF) before applying the `SriovNetworkNodePolicy` resource. If the VFs are not pre-created, the SR-IOV Network Operator's webhook will block the policy request. +When `externallyManaged` is set to `true`, you must manually create the Virtual Functions (VFs) on the physical function (PF) before applying the `SriovNetworkNodePolicy` resource. If the VFs are not pre-created, the SR-IOV Network Operator's webhook will block the policy request. When `externallyManaged` is set to `false`, the SR-IOV Network Operator automatically creates and manages the VFs, including resetting them if necessary. @@ -109,7 +109,7 @@ When `linkType` is set to `ib`, `isRdma` is automatically set to `true` by the S + Do not set linkType to `eth` for SriovNetworkNodePolicy, because this can lead to an incorrect number of available devices reported by the device plugin. -<19> Optional: To enable hardware offloading, you must set the `eSwitchMode` field to `"switchdev"`. For more information about hardware offloading , see "Configuring hardware offloading". +<19> Optional: To enable hardware offloading, you must set the `eSwitchMode` field to `"switchdev"`. For more information about hardware offloading, see "Configuring hardware offloading". <20> Optional: To exclude advertising an SR-IOV network resource's NUMA node to the Topology Manager, set the value to `true`. The default value is `false`. @@ -163,4 +163,4 @@ spec: <1> The `numVfs` field is always set to `1` when configuring the node network policy for a virtual machine. -<2> The `netFilter` field must refer to a network ID when the virtual machine is deployed on {rh-openstack}. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object. \ No newline at end of file +<2> The `netFilter` field must refer to a network ID when the virtual machine is deployed on {rh-openstack}. Valid values for `netFilter` are available from an `SriovNetworkNodeState` object. diff --git a/modules/oadp-usecase-include-ca-cert-backup.adoc b/modules/oadp-usecase-include-ca-cert-backup.adoc index 075e7f9bc2..8e0c39139e 100644 --- a/modules/oadp-usecase-include-ca-cert-backup.adoc +++ b/modules/oadp-usecase-include-ca-cert-backup.adoc @@ -6,7 +6,7 @@ [id="oadp-usecase-include-ca-cert-backup_{context}"] = Backing up an application and its self-signed CA certificate -The `s3.openshift-storage.svc` service, provided by {odf-short}, uses a Transport Layer Security protocol (TLS) certificate that is signed with the self-signed service CA. +The `s3.openshift-storage.svc` service, provided by {odf-short}, uses a Transport Layer Security protocol (TLS) certificate that is signed with the self-signed service CA. To prevent a `certificate signed by unknown authority` error, you must include a self-signed CA certificate in the backup storage location (BSL) section of `DataProtectionApplication` custom resource (CR). For this situation, you must complete the following tasks: @@ -71,11 +71,11 @@ backup-c20...41fd s3.openshift-storage.svc ---- -. To get the bucket credentials from the `secret` object , run the following command: +. To get the bucket credentials from the `secret` object, run the following command: + [source,terminal] ---- -$ oc extract --to=- secret/test-obc +$ oc extract --to=- secret/test-obc ---- + .Example output @@ -92,8 +92,8 @@ YXf...+NaCkdyC3QPym [source,terminal] ---- [default] -aws_access_key_id= -aws_secret_access_key= +aws_access_key_id= +aws_secret_access_key= ---- . Create the `cloud-credentials` secret with the `cloud-credentials` file content by running the following command: @@ -142,20 +142,20 @@ spec: - aws - openshift - csi - defaultSnapshotMoveData: true + defaultSnapshotMoveData: true backupLocations: - velero: config: profile: "default" region: noobaa - s3Url: https://s3.openshift-storage.svc - s3ForcePathStyle: "true" + s3Url: https://s3.openshift-storage.svc + s3ForcePathStyle: "true" insecureSkipTLSVerify: "false" # <1> provider: aws default: true credential: key: cloud - name: cloud-credentials + name: cloud-credentials objectStorage: bucket: # <2> prefix: oadp @@ -169,7 +169,7 @@ spec: + [source,terminal] ---- -$ oc apply -f +$ oc apply -f ---- . Verify that the `DataProtectionApplication` CR is created successfully by running the following command: @@ -211,7 +211,7 @@ metadata: + [source,terminal] ---- -$ oc get backupstoragelocations.velero.io -n openshift-adp +$ oc get backupstoragelocations.velero.io -n openshift-adp ---- + .Example output @@ -241,7 +241,7 @@ spec: + [source,terminal] ---- -$ oc apply -f +$ oc apply -f ---- .Verification @@ -250,7 +250,7 @@ $ oc apply -f + [source,terminal] ---- -$ oc describe backup test-backup -n openshift-adp +$ oc describe backup test-backup -n openshift-adp ---- + .Example output @@ -273,4 +273,4 @@ Status: Start Timestamp: 2024-09-25T10:16:31Z Version: 1 Events: ----- \ No newline at end of file +---- diff --git a/modules/telco-observability-key-performance-metrics.adoc b/modules/telco-observability-key-performance-metrics.adoc index 0896bde6ea..486e061357 100644 --- a/modules/telco-observability-key-performance-metrics.adoc +++ b/modules/telco-observability-key-performance-metrics.adoc @@ -17,11 +17,11 @@ Here are some key metrics that you should pay attention to: * OVN health * Overall cluster operator health -A good rule to follow is that if you decide that a metric is important, there should be an alert for it. +A good rule to follow is that if you decide that a metric is important, there should be an alert for it. [NOTE] ==== -You can check the available metrics by runnning the following command: +You can check the available metrics by running the following command: [source,terminal] ---- $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk http://localhost:9090/api/v1/metadata | jq '.data @@ -31,12 +31,12 @@ $ oc -n openshift-monitoring exec -c prometheus prometheus-k8s-0 -- curl -qsk ht [id="example-queries-promql"] == Example queries in PromQL -The following tables show some queries that you can explore in the metrics query browser using the {product-title} console. +The following tables show some queries that you can explore in the metrics query browser using the {product-title} console. [NOTE] ==== The URL for the console is https:///monitoring/query-browser. -You can get the Openshift Console FQDN by runnning the following command: +You can get the Openshift Console FQDN by running the following command: [source,terminal] ---- $ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].host}' @@ -79,7 +79,7 @@ $ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].ho |`POST` |`histogram_quantile (0.99, sum by (le,managed_cluster) (sum_over_time(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver\|openshift-apiserver", verb="POST"}[60m])))` -|`LIST` +|`LIST` |`histogram_quantile (0.99, sum by (le,managed_cluster) (sum_over_time(apiserver_request_duration_seconds_bucket{apiserver="kube-apiserver\|openshift-apiserver", verb="LIST"}[60m])))` |`PUT` @@ -130,14 +130,14 @@ $ oc get routes -n openshift-console console -o jsonpath='{.status.ingress[0].ho [id="recommendations-for-storage-of-metrics"] == Recommendations for storage of metrics -Out of the box, Prometheus does not back up saved metrics with persistent storage. -If you restart the Prometheus pods, all metrics data are lost. -You should configure the monitoring stack to use the back-end storage that is available on the platform. +Out of the box, Prometheus does not back up saved metrics with persistent storage. +If you restart the Prometheus pods, all metrics data are lost. +You should configure the monitoring stack to use the back-end storage that is available on the platform. To meet the high IO demands of Prometheus you should use local storage. -For Telco core clusters, you can use the Local Storage Operator for persistent storage for Prometheus. +For Telco core clusters, you can use the Local Storage Operator for persistent storage for Prometheus. {odf-first}, which deploys a ceph cluster for block, file, and object storage, is also a suitable candidate for a Telco core cluster. -To keep system resource requirements low on a RAN {sno} or far edge cluster, you should not provision backend storage for the monitoring stack. -Such clusters forward all metrics to the hub cluster where you can provision a third party monitoring platform. \ No newline at end of file +To keep system resource requirements low on a RAN {sno} or far edge cluster, you should not provision backend storage for the monitoring stack. +Such clusters forward all metrics to the hub cluster where you can provision a third party monitoring platform. diff --git a/modules/telco-troubleshooting-mco-purpose.adoc b/modules/telco-troubleshooting-mco-purpose.adoc index 231e44c8af..c647f55b9e 100644 --- a/modules/telco-troubleshooting-mco-purpose.adoc +++ b/modules/telco-troubleshooting-mco-purpose.adoc @@ -14,6 +14,6 @@ You must consider these minor components and how the MCO can help you manage you [IMPORTANT] ==== -You must use the the MCO to perform all changes on worker or control plane nodes. +You must use the MCO to perform all changes on worker or control plane nodes. Do not manually make changes to {op-system} or node files. -==== \ No newline at end of file +==== diff --git a/modules/virt-configuring-vm-use-usb-device.adoc b/modules/virt-configuring-vm-use-usb-device.adoc index 2252a476bc..0ded097d06 100644 --- a/modules/virt-configuring-vm-use-usb-device.adoc +++ b/modules/virt-configuring-vm-use-usb-device.adoc @@ -17,7 +17,7 @@ You can configure virtual machine (VM) access to a USB device. This configuratio $ oc /dev/serial/by-id/usb-VENDOR_device_name ---- -. Open the virtual machine instance custom resource (CR) by running the following commmand: +. Open the virtual machine instance custom resource (CR) by running the following command: + [source,terminal] ---- @@ -44,4 +44,3 @@ spec: # ... ---- <1> The name of the USB device. - diff --git a/modules/virt-enabling-usb-host-passthrough.adoc b/modules/virt-enabling-usb-host-passthrough.adoc index 68059c2edd..232563047e 100644 --- a/modules/virt-enabling-usb-host-passthrough.adoc +++ b/modules/virt-enabling-usb-host-passthrough.adoc @@ -23,7 +23,7 @@ You specify a resource name and USB device name for each device you want first t $ lsusb ---- -. Open the HCO CR by running the following commmand: +. Open the HCO CR by running the following command: + [source,terminal] ---- @@ -57,4 +57,4 @@ spec: ---- <1> Lists the host devices that have permission to be used in the cluster. <2> Lists the available USB devices. -<3> Uses `resourceName: deviceName` for each device you want to add and assign to the VM. In this example, the resource is bound to three devices, each of which is identified by `vendor` and `product` and is known as a `selector`. \ No newline at end of file +<3> Uses `resourceName: deviceName` for each device you want to add and assign to the VM. In this example, the resource is bound to three devices, each of which is identified by `vendor` and `product` and is known as a `selector`. diff --git a/networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc b/networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc index 5f4e002c0d..51eb5bf173 100644 --- a/networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc +++ b/networking/multiple_networks/primary_networks/about-primary-nwt-nad.adoc @@ -21,7 +21,7 @@ Each approach is mutually exclusive and you can only use one approach for managi [NOTE] ==== -When deploying {product-title} nodes with multiple network interfaces on {rh-openstack-first} with OVN SDN, DNS configuration of the secondary interface might take precedence over the DNS configuration of the primary interface. In this case, remove the DNS nameservers for the the subnet ID that is attached to the secondary interface by running the following command: +When deploying {product-title} nodes with multiple network interfaces on {rh-openstack-first} with OVN SDN, DNS configuration of the secondary interface might take precedence over the DNS configuration of the primary interface. In this case, remove the DNS nameservers for the subnet ID that is attached to the secondary interface by running the following command: [source,terminal] ---- @@ -33,4 +33,4 @@ include::modules/nw-multus-create-network.adoc[leveloffset=+1] include::modules/nw-nad-cr.adoc[leveloffset=+1] -include::modules/nw-multus-create-network-apply.adoc[leveloffset=+1] \ No newline at end of file +include::modules/nw-multus-create-network-apply.adoc[leveloffset=+1] diff --git a/windows_containers/enabling-windows-container-workloads.adoc b/windows_containers/enabling-windows-container-workloads.adoc index 1922813516..8c235a406b 100644 --- a/windows_containers/enabling-windows-container-workloads.adoc +++ b/windows_containers/enabling-windows-container-workloads.adoc @@ -69,7 +69,7 @@ include::modules/images-configuration-registry-mirror-configuring.adoc[leveloffs include::modules/nodes-nodes-rebooting-gracefully.adoc[leveloffset=+1] -.Additional references +.Additional resources * xref:../nodes/nodes/nodes-nodes-rebooting.adoc#nodes-nodes-rebooting-gracefully_nodes-nodes-rebooting[Rebooting a {product-title} node gracefully] * xref:../backup_and_restore/control_plane_backup_and_restore/backing-up-etcd.adoc#backup-etcd[Backing up etcd data] @@ -78,4 +78,3 @@ include::modules/nodes-nodes-rebooting-gracefully.adoc[leveloffset=+1] * xref:../installing/installing_azure/ipi/installing-azure-default.adoc#ssh-agent-using_installing-azure-default[Generating a key pair for cluster node SSH access] * xref:../operators/admin/olm-adding-operators-to-cluster.adoc#olm-adding-operators-to-a-cluster[Adding Operators to a cluster] -