Merge pull request #1484 from marquiz/devel/docs-styling

docs: styling

docs/deployment/helm.md

@@ -15,7 +15,7 @@ sort: 3
 
 ---
 
-Node Feature Discovery Helm chart allow to easily deploy and manage NFD.
+Node Feature Discovery provides a Helm chart to manage its deployment.
 
 > **NOTE:** NFD is not ideal for other Helm charts to depend on as that may
 > result in multiple parallel NFD deployments in the same cluster which is not
@@ -49,7 +49,7 @@ helm install node-feature-discovery ./node-feature-discovery/ --namespace $NFD_N
 See the [configuration](#configuration) section below for instructions how to
 alter the deployment parameters.
 
-In order to deploy the [minimal](image-variants.md#minimal) image you need to
+To deploy the [minimal](image-variants.md#minimal) image you need to
 override the image tag:
 
 ```bash
@@ -86,8 +86,8 @@ deletes the release.
 
 ## Chart parameters
 
-In order to tailor the deployment of the Node Feature Discovery to your cluster needs
-We have introduced the following Chart parameters.
+To tailor the deployment of the Node Feature Discovery to your needs following
+Chart parameters are available.
 
 ### General parameters
 

docs/deployment/image-variants.md

@@ -9,8 +9,8 @@ sort: 1
 
 ---
 
-NFD currently offers two variants of the container image. The "minimal" variant is
-currently deployed by default. Released container images are available for
+NFD offers two variants of the container image. The "minimal" variant is
+deployed by default. Released container images are available for
 x86_64 and Arm64 architectures.
 
 ## Minimal

docs/deployment/kustomize.md

@@ -15,8 +15,8 @@ sort: 2
 
 ---
 
-[Kustomize](https://github.com/kubernetes-sigs/kustomize) provides easy
-deployment of NFD. Customization of the deployment is done by maintaining
+[Kustomize](https://github.com/kubernetes-sigs/kustomize) can be used to
+deploy NFD. Customization of the deployment is done by maintaining
 declarative overlays on top of the base overlays in NFD.
 
 To follow the deployment instructions here,
@@ -33,7 +33,7 @@ This will required RBAC rules and deploy nfd-master (as a deployment) and
 nfd-worker (as daemonset) in the `node-feature-discovery` namespace.
 
 > **NOTE:** nfd-topology-updater is not deployed as part of the `default`
-> overlay.  Please refer to the [Master Worker Topologyupdater](#master-worker-topologyupdater)
+> overlay. Refer to the [Master Worker Topologyupdater](#master-worker-topologyupdater)
 > and [Topologyupdater](#topologyupdater) below.
 
 Alternatively you can clone the repository and customize the deployment by
@@ -120,7 +120,7 @@ kubectl apply -k https://github.com/kubernetes-sigs/node-feature-discovery/deplo
 
 ### Topologyupdater
 
-In order to deploy just nfd-topology-updater (without nfd-master and nfd-worker)
+To deploy just nfd-topology-updater (without nfd-master and nfd-worker)
 use the `topologyupdater` overlay:
 
 ```bash

docs/deployment/metrics.md

@@ -48,7 +48,7 @@ to scrape metrics from NFD, you need to pass the following values to Helm:
 
 For more info on Helm deployment, see [Helm](helm.md).
 
-We recommend setting
+It is recommended to specify
 `--set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValues=false`
 when deploying prometheus-operator via Helm to enable the prometheus-operator
 to scrape metrics from any PodMonitor.

docs/deployment/operator.md

@@ -59,7 +59,7 @@ is recommended to be done via
    EOF
    ```
 
-In order to deploy the [minimal](image-variants.md#minimal) image you need to use
+To deploy the [minimal](image-variants.md#minimal) image you need to use
 
 ```yaml
   image: {{ site.container_image }}-minimal
@@ -69,7 +69,7 @@ in the `NodeFeatureDiscovery` object above.
 
 ## Uninstallation
 
-If you followed the deployment instructions above you can simply do:
+If you followed the deployment instructions above you can uninstall NFD with:
 
 ```bash
 kubectl -n nfd delete NodeFeatureDiscovery my-nfd-deployment

docs/deployment/tls.md

@@ -49,14 +49,15 @@ The NFD source code repository contains an example kustomize overlay and helm
 chart that can be used to deploy NFD with cert-manager supplied certificates
 enabled.
 
-To install `cert-manager` itself can be done as easily as this, below, or you
-can refer to their documentation for other installation methods such as the
-helm chart they provide.
+To install `cert-manager` itself, you can run:
 
 ```bash
 kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml
 ```
 
+Alternatively, you can refer to cert-manager documentation for other
+installation methods such as the Helm chart they provide.
+
 To use the kustomize overlay to install node-feature-discovery with TLS enabled,
 you may use the following:
 

docs/developer-guide/index.md

@@ -125,7 +125,7 @@ makefile overrides.
 | KUBECONFIG                 | Kubeconfig for running e2e-tests                                  | *empty* |
 | E2E_TEST_CONFIG            | Parameterization file of e2e-tests (see [example][e2e-config-sample]) | *empty* |
 | E2E_PULL_IF_NOT_PRESENT    | True-ish value makes the image pull policy IfNotPresent (to be used only in e2e tests) | false |
-| OPENSHIFT                  | Non-empty value enables OpenShift specific support (currently only effective in e2e tests) | *empty* |
+| OPENSHIFT                  | Non-empty value enables OpenShift specific support (only affects e2e tests) | *empty* |
 
 For example, to use a custom registry:
 
@@ -150,7 +150,7 @@ Or to specify a build tool different from Docker, It can be done in 2 ways:
 ### Testing
 
 Unit tests are automatically run as part of the container image build. You can
-also run them manually in the source code tree by simply running:
+also run them manually in the source code tree by running:
 
 ```bash
 make test
@@ -191,8 +191,8 @@ $ docker run --rm --name=nfd-test ${NFD_CONTAINER_IMAGE} nfd-master -no-publish
 
 ### NFD-Worker
 
-In order to run nfd-worker as a "stand-alone" container
-you need to run it in the same network namespace as the nfd-master container:
+To run nfd-worker as a "stand-alone" container you need to run it in the same
+network namespace as the nfd-master container:
 
 ```bash
 $ docker run --rm --network=container:nfd-test ${NFD_CONTAINER_IMAGE} nfd-worker -enable-nodefeature-api=false
@@ -205,14 +205,14 @@ pass the `-no-publish` flag to nfd-worker.
 
 > **NOTE:** Some feature sources need certain directories and/or files from the
 > host mounted inside the NFD container. Thus, you need to provide Docker with
-> the correct `--volume` options in order for them to work correctly when run
+> the correct `--volume` options for them to work correctly when run
 > stand-alone directly with `docker run`. See
 > the [default deployment](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/components/common/worker-mounts.yaml)
 > for up-to-date information about the required volume mounts.
 
 ### NFD-Topology-Updater
 
-In order to run nfd-topology-updater as a "stand-alone" container
+To run nfd-topology-updater as a "stand-alone" container
 you need to run it in with the `-no-publish` flag to disable communication to
 the Kubernetes apiserver.
 
@@ -227,7 +227,7 @@ the Kubernetes API, pass the `-no-publish` flag to nfd-topology-updater.
 
 > **NOTE:** NFD topology updater needs certain directories and/or files from
 > the host mounted inside the NFD container. Thus, you need to provide Docker
-> with the correct `--volume` options in order for them to work correctly when
+> with the correct `--volume` options for them to work correctly when
 > run stand-alone directly with `docker run`. See
 > the [template spec](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/components/topology-updater/topologyupdater-mounts.yaml)
 > for up-to-date information about the required volume mounts.
@@ -257,7 +257,7 @@ the steps below.
 1. Install [tilt](https://docs.tilt.dev/install.html)
 1. Create a local Kubernetes cluster
 
-To start up your Tilt development environment, just run
+To start up your Tilt development environment, run
 
 ```shell
 tilt up
@@ -290,7 +290,7 @@ All documentation resides under the
 directory in the source tree. It is designed to be served as a html site by
 [GitHub Pages](https://pages.github.com/).
 
-Building the documentation is containerized in order to fix the build
+Building the documentation is containerized to fix the build
 environment. The recommended way for developing documentation is to run:
 
 ```bash
@@ -300,10 +300,9 @@ make site-serve
 This will build the documentation in a container and serve it under
 [localhost:4000/](http://localhost:4000/) making it easy to verify the results.
 Any changes made to the `docs/` will automatically re-trigger a rebuild and are
-reflected in the served content and can be inspected with a simple browser
-refresh.
+reflected in the served content and can be inspected with a browser refresh.
 
-In order to just build the html documentation run:
+To just build the html documentation run:
 
 ```bash
 make site-build

docs/get-started/quick-start.md

@@ -78,7 +78,7 @@ feature-dependent-pod   1/1     Running   0          23s   10.36.0.4   node-2
 
 ### Deploy nfd-topology-updater
 
-In order to deploy nfd-topology-updater use the `topologyupdater` kustomize
+To deploy nfd-topology-updater use the `topologyupdater` kustomize
 overlay.
 
 ```bash

docs/reference/master-commandline-reference.md

@@ -87,7 +87,7 @@ The `-ca-file` is one of the three flags (together with `-cert-file` and
 `-key-file`) controlling master-worker mutual TLS authentication on the
 nfd-master side. This flag specifies the TLS root certificate that is used for
 authenticating incoming connections. NFD-Worker side needs to have matching key
-and cert files configured in order for the incoming requests to be accepted.
+and cert files configured for the incoming requests to be accepted.
 
 Default: *empty*
 
@@ -243,8 +243,8 @@ nfd-master -crd-controller=false
 ### -label-whitelist
 
 The `-label-whitelist` specifies a regular expression for filtering feature
-labels based on their name. Each label must match against the given reqular
-expression in order to be published.
+labels based on their name. Each label must match against the given regular
+expression or it will not be published.
 
 > **NOTE:** The regular expression is only matches against the "basename" part
 > of the label, i.e. to the part of the name after '/'. The label namespace is

docs/reference/master-configuration-reference.md

@@ -78,7 +78,7 @@ default `feature.node.kubernetes.io/` prefix to unprefixed labels, annotations
 and extended resources - this is also the default behavior in NFD v0.13 and
 earlier. When the option is set to `false`, no prefix will be prepended to
 unprefixed names, effectively causing them to be filtered out (as NFD does not
-currently allow unprefixed names of labels, annotations or extended resources).
+allow unprefixed names of labels, annotations or extended resources).
 The default will be changed to `false` in a future release.
 
 For example, with the `autoDefaultNs` set to `true`, a NodeFeatureRule with
@@ -132,8 +132,8 @@ enableTaints: true
 
 ## labelWhiteList
 `labelWhiteList` specifies a regular expression for filtering feature
-labels based on their name. Each label must match against the given reqular
-expression in order to be published.
+labels based on their name. Each label must match against the given regular
+expression or it will not be published.
 
 > ** NOTE:** The regular expression is only matches against the "basename" part
 > of the label, i.e. to the part of the name after '/'. The label namespace is

docs/usage/customization-guide.md

@@ -199,7 +199,7 @@ further be used in label rules specified in
 [`custom`](#custom-feature-source) feature source.
 
 > **NOTE:** Be careful when creating and/or updating hook or feature files
-> while NFD is running. In order to avoid race conditions you should write
+> while NFD is running. To avoid race conditions you should write
 > into a temporary file, and atomically create/update the original file by
 > doing a file rename operation. NFD ignores dot files,
 > so temporary file can be written to the same directory and renamed
@@ -247,7 +247,7 @@ debugging and logging.
 
 NFD tries to execute any regular files found from the hooks directory.
 Any additional data files the hook might need (e.g. a configuration file)
-should be placed in a separate directory in order to avoid NFD unnecessarily
+should be placed in a separate directory to avoid NFD unnecessarily
 trying to execute them. A subdirectory under the hooks directory can be used,
 for example `/etc/kubernetes/node-feature-discovery/source.d/conf/`.
 
@@ -316,7 +316,7 @@ vendor.io/feature4=featureValue4
 After processing the above file, only `vendor.io/feature2` and
 `vendor.io/feature3` would be included in the list of accepted features.
 
-> **NOTE:** The time format that we are supporting is RFC3339. Also, the `expiry-time`
+> **NOTE:** The time format supported is RFC3339. Also, the `expiry-time`
 > tag is only evaluated in each re-discovery period, and the expiration of
 > node labels is not tracked.
 
@@ -753,7 +753,7 @@ the usage of vars.
 
 The `.matchFeatures` field specifies a feature matcher, consisting of a list of
 feature matcher terms. It implements a logical AND over the terms i.e. all
-of them must match in order for the rule to trigger.
+of them must match for the rule to trigger.
 
 ```yaml
       matchFeatures:
@@ -801,7 +801,7 @@ separately.
 
 The `.matchAny` field is a list of of [`matchFeatures`](#matchfeatures)
 matchers. A logical OR is applied over the matchers, i.e. at least one of them
-must match in order for the rule to trigger.
+must match for the rule to trigger.
 
 Consider the following example:
 
@@ -1030,7 +1030,7 @@ advertising the number of PCI network controllers from a specific vendor:
 ```
 
 <!-- {% endraw %} -->
-Imaginative template pipelines are possible, but care must be taken in order to
+Imaginative template pipelines are possible, but care must be taken to
 produce understandable and maintainable rule sets.
 
 ### Backreferences

docs/usage/nfd-master.md

@@ -83,7 +83,7 @@ NFD-Master runs as a deployment, by default
 it prefers running on the cluster's master nodes but will run on worker
 nodes if no master nodes are found.
 
-For High Availability, you should simply increase the replica count of
+For High Availability, you should increase the replica count of
 the deployment object. You should also look into adding
 [inter-pod](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)
 affinity to prevent masters from running on the same node.
@@ -97,5 +97,5 @@ in bigger clusters.
 
 If you have RBAC authorization enabled (as is the default e.g. with clusters
 initialized with kubeadm) you need to configure the appropriate ClusterRoles,
-ClusterRoleBindings and a ServiceAccount in order for NFD to create node
+ClusterRoleBindings and a ServiceAccount for NFD to create node
 labels. The provided template will configure these for you.

docs/usage/nfd-topology-updater.md

@@ -62,8 +62,7 @@ NFD-Topology-Updater supports configuration through a configuration file. The
 default location is `/etc/kubernetes/node-feature-discovery/topology-updater.conf`,
 but, this can be changed by specifying the`-config` command line flag.
 
-> **NOTE:** unlike nfd-worker, dynamic configuration updates are not currently
-> supported.
+> **NOTE:** unlike nfd-worker, dynamic configuration updates are not supported.
 
 Topology-Updater configuration file is read inside the container,
 and thus, Volumes and VolumeMounts are needed

docs/usage/nfd-worker.md

@@ -20,7 +20,7 @@ This can be changed by using the
 config option.
 
 The worker configuration file is watched and re-read on every change which
-provides a simple mechanism of dynamic run-time reconfiguration. See
+provides a mechanism of dynamic run-time reconfiguration. See
 [worker configuration](#worker-configuration) for more details.
 
 ## Worker configuration