diff --git a/metering/metering-installing-metering.adoc b/metering/metering-installing-metering.adoc index 54cd70b083..7448dae487 100644 --- a/metering/metering-installing-metering.adoc +++ b/metering/metering-installing-metering.adoc @@ -5,7 +5,7 @@ include::modules/common-attributes.adoc[] toc::[] -Review the the following sections before installing metering into your cluster. +Review the following sections before installing metering into your cluster. To get started installing metering, first install the Metering Operator from OperatorHub. Next, configure your instance of metering by creating a `CustomResource`, referred to here as your MeteringConfig. Installing the Metering Operator creates a default MeteringConfig that you can modify using the examples in the documentation. After creating your MeteringConfig, install the metering stack. Last, verify your installation. diff --git a/modules/apis.adoc b/modules/apis.adoc index ebc80812d1..1d8126d3df 100644 --- a/modules/apis.adoc +++ b/modules/apis.adoc @@ -71997,7 +71997,7 @@ The following table describes the parameters for the ImageStreamImport object: | Spec is a description of the images that the user wishes to import | `status` | ImageStreamImportStatus -| Status is the the result of importing the image +| Status is the result of importing the image |=== ==== ImageStreamImportSpec [v1/image.openshift.io] diff --git a/modules/cluster-logging-upgrading-logging.adoc b/modules/cluster-logging-upgrading-logging.adoc index 0030278097..b0b1dea0ac 100644 --- a/modules/cluster-logging-upgrading-logging.adoc +++ b/modules/cluster-logging-upgrading-logging.adoc @@ -11,7 +11,7 @@ After updating the {product-title} cluster, you can update cluster logging from ==== Changes introduced by the new log forward feature modified the support for *out_forward* starting with the {product-title} 4.3 release. In {product-title} 4.3, you create a ConfigMap to configure *out_forward*. Any updates to the `secure-forward.conf` section of the Fluentd ConfigMap are removed. -If you use the the *out_forward* plug-in, before updating, you can copy your current `secure-forward.conf` section from the Fluentd ConfigMap and use the copied data when you create the `secure-forward` ConfigMap. +If you use the *out_forward* plug-in, before updating, you can copy your current `secure-forward.conf` section from the Fluentd ConfigMap and use the copied data when you create the `secure-forward` ConfigMap. ==== .Prerequisites diff --git a/modules/nodes-cluster-disabling-features-cluster.adoc b/modules/nodes-cluster-disabling-features-cluster.adoc index d934b8c450..dbd2606c3f 100644 --- a/modules/nodes-cluster-disabling-features-cluster.adoc +++ b/modules/nodes-cluster-disabling-features-cluster.adoc @@ -30,7 +30,7 @@ cluster 18d ---- . Edit the FeatureGate: -.. From the web console, switch to the the +.. From the web console, switch to the *Administration* -> *Custom Resource Definitions* page. .. On the *Custom Resource Definitions* page, click *FeatureGate*. diff --git a/modules/nw-networkpolicy-multitenant-isolation.adoc b/modules/nw-networkpolicy-multitenant-isolation.adoc index 4d80c10aaf..b947eb15c6 100644 --- a/modules/nw-networkpolicy-multitenant-isolation.adoc +++ b/modules/nw-networkpolicy-multitenant-isolation.adoc @@ -68,7 +68,7 @@ $ oc apply -f .yaml \ <1> <2> Replace `` with the name of the project to apply the NetworkPolicy object to. -. If the `default` Ingress Controller configuration has the `spec.endpointPublishingStrategy: HostNetwork` value set, you must apply a label to the the `default` {product-title} namespace to allow network traffic between the Ingress Controller and the project: +. If the `default` Ingress Controller configuration has the `spec.endpointPublishingStrategy: HostNetwork` value set, you must apply a label to the `default` {product-title} namespace to allow network traffic between the Ingress Controller and the project: .. Determine if your `default` Ingress Controller uses the `HostNetwork` endpoint publishing strategy: + diff --git a/modules/nw-sriov-dpdk-example-mellanox.adoc b/modules/nw-sriov-dpdk-example-mellanox.adoc index bec2dc0a66..88e43b5944 100644 --- a/modules/nw-sriov-dpdk-example-mellanox.adoc +++ b/modules/nw-sriov-dpdk-example-mellanox.adoc @@ -32,7 +32,7 @@ spec: ---- <1> Specify the device hex code of the SR-IOV network device. The only allowed values for Mellanox cards are `1015`, `1017`. -<2> Specify the driver type for the the virtual functions to `netdevice`. Mellanox SR-IOV VF can work in DPDK mode without using the `vfio-pci` device type. VF device appears as a kernel network interface inside a container. +<2> Specify the driver type for the virtual functions to `netdevice`. Mellanox SR-IOV VF can work in DPDK mode without using the `vfio-pci` device type. VF device appears as a kernel network interface inside a container. <3> Enable RDMA mode. This is required by Mellanox cards to work in DPDK mode. [NOTE] @@ -122,7 +122,7 @@ spec: ---- <1> Specify the same `target_namespace` where SriovNetwork CR `mlx-dpdk-network` is created. If you would like to create the Pod in a different namespace, change `target_namespace` in both Pod spec and SriovNetowrk CR. -<2> Specify the the DPDK image which includes your application and the DPDK library used by application. +<2> Specify the DPDK image which includes your application and the DPDK library used by application. <3> Specify the `IPC_LOCK` capability which is required by the application to allocate hugepage memory inside the container. <4> Mount the hugepage volume to the DPDK Pod under `/dev/hugepages`. The hugepage volume is backed by the emptyDir volume type with the medium being `Hugepages`. <5> (optional) Specify the number of DPDK devices allocated to the DPDK Pod. This resource request and limit, if not explicitly specified, will be automatically added by SR-IOV network resource injector. The SR-IOV network resource injector is an admission controller component managed by SR-IOV Operator. It is enabled by default and can be disabled by setting the `Injector` option to `false` in the default `SriovOperatorConfig` CR. diff --git a/modules/private-clusters-setting-api-private.adoc b/modules/private-clusters-setting-api-private.adoc index 727ff9d184..4d615edfc3 100644 --- a/modules/private-clusters-setting-api-private.adoc +++ b/modules/private-clusters-setting-api-private.adoc @@ -17,7 +17,7 @@ After you deploy a cluster to Amazon Web Services (AWS) or Microsoft Azure, you . In the web portal or console for AWS or Azure, take the following actions: .. Locate and delete appropriate load balancer component. -*** For AWS, delete the the external load balancer. The API DNS entry in the private zone already points to the internal load balancer, which uses an identical configuration, so you do not need to modify the internal load balancer. +*** For AWS, delete the external load balancer. The API DNS entry in the private zone already points to the internal load balancer, which uses an identical configuration, so you do not need to modify the internal load balancer. *** For Azure, delete the `api-internal` rule for the load balancer. .. Delete the `api.$clustername.$yourdomain` DNS entry in the public zone.