mirrors/node-feature-discovery
mirrors/node-feature-discovery
1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2025-03-16 21:38:23 +00:00
Code Activity

docs: streamline language

Browse source
This commit is contained in:
Markus Lehtonen 2023-12-01 15:55:45 +02:00
parent 4d56ffae8f
commit 15dc917ddb
9 changed files with 21 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/deployment/helm.md
View file

@ -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 See the [configuration](#configuration) section below for instructions how to
alter the deployment parameters. 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: override the image tag:
```bash ```bash

4
docs/deployment/kustomize.md
View file

@ -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. nfd-worker (as daemonset) in the `node-feature-discovery` namespace.
> **NOTE:** nfd-topology-updater is not deployed as part of the `default` > **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. > and [Topologyupdater](#topologyupdater) below.
Alternatively you can clone the repository and customize the deployment by 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 ### 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: use the `topologyupdater` overlay:
```bash ```bash

2
docs/deployment/operator.md
View file

@ -59,7 +59,7 @@ is recommended to be done via
EOF 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 ```yaml
image: {{ site.container_image }}-minimal image: {{ site.container_image }}-minimal

14
docs/developer-guide/index.md
View file

@ -191,8 +191,8 @@ $ docker run --rm --name=nfd-test ${NFD_CONTAINER_IMAGE} nfd-master -no-publish
### NFD-Worker ### NFD-Worker
In order to run nfd-worker as a "stand-alone" container To run nfd-worker as a "stand-alone" container you need to run it in the same
you need to run it in the same network namespace as the nfd-master container: network namespace as the nfd-master container:
```bash ```bash
$ docker run --rm --network=container:nfd-test ${NFD_CONTAINER_IMAGE} nfd-worker -enable-nodefeature-api=false $ 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 > **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 > 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 > 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) > 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. > for up-to-date information about the required volume mounts.
### NFD-Topology-Updater ### 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 you need to run it in with the `-no-publish` flag to disable communication to
the Kubernetes apiserver. 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 > **NOTE:** NFD topology updater needs certain directories and/or files from
> the host mounted inside the NFD container. Thus, you need to provide Docker > 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 > 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) > 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. > for up-to-date information about the required volume mounts.
@ -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 directory in the source tree. It is designed to be served as a html site by
[GitHub Pages](https://pages.github.com/). [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: environment. The recommended way for developing documentation is to run:
```bash ```bash
@ -302,7 +302,7 @@ This will build the documentation in a container and serve it under
Any changes made to the `docs/` will automatically re-trigger a rebuild and are 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 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 ```bash
make site-build make site-build

2
docs/get-started/quick-start.md
View file

@ -78,7 +78,7 @@ feature-dependent-pod 1/1 Running 0 23s 10.36.0.4 node-2
### Deploy nfd-topology-updater ### 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. overlay.
```bash ```bash

4
docs/reference/master-commandline-reference.md
View file

@ -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 `-key-file`) controlling master-worker mutual TLS authentication on the
nfd-master side. This flag specifies the TLS root certificate that is used for 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 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* Default: *empty*
@ -244,7 +244,7 @@ nfd-master -crd-controller=false
The `-label-whitelist` specifies a regular expression for filtering feature The `-label-whitelist` specifies a regular expression for filtering feature
labels based on their name. Each label must match against the given regular labels based on their name. Each label must match against the given regular
expression in order to be published. expression or it will not be published.
> **NOTE:** The regular expression is only matches against the "basename" part > **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 > of the label, i.e. to the part of the name after '/'. The label namespace is

2
docs/reference/master-configuration-reference.md
View file

@ -133,7 +133,7 @@ enableTaints: true
## labelWhiteList ## labelWhiteList
`labelWhiteList` specifies a regular expression for filtering feature `labelWhiteList` specifies a regular expression for filtering feature
labels based on their name. Each label must match against the given regular labels based on their name. Each label must match against the given regular
expression in order to be published. expression or it will not be published.
> ** NOTE:** The regular expression is only matches against the "basename" part > ** 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 > of the label, i.e. to the part of the name after '/'. The label namespace is

10
docs/usage/customization-guide.md
View file

@ -199,7 +199,7 @@ further be used in label rules specified in
[`custom`](#custom-feature-source) feature source. [`custom`](#custom-feature-source) feature source.
> **NOTE:** Be careful when creating and/or updating hook or feature files > **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 > into a temporary file, and atomically create/update the original file by
> doing a file rename operation. NFD ignores dot files, > doing a file rename operation. NFD ignores dot files,
> so temporary file can be written to the same directory and renamed > 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. 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) 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, trying to execute them. A subdirectory under the hooks directory can be used,
for example `/etc/kubernetes/node-feature-discovery/source.d/conf/`. for example `/etc/kubernetes/node-feature-discovery/source.d/conf/`.
@ -753,7 +753,7 @@ the usage of vars.
The `.matchFeatures` field specifies a feature matcher, consisting of a list of 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 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 ```yaml
matchFeatures: matchFeatures:
@ -801,7 +801,7 @@ separately.
The `.matchAny` field is a list of of [`matchFeatures`](#matchfeatures) 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 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: Consider the following example:
@ -1030,7 +1030,7 @@ advertising the number of PCI network controllers from a specific vendor:
``` ```
<!-- {% endraw %} --> <!-- {% 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. produce understandable and maintainable rule sets.
### Backreferences ### Backreferences

2
docs/usage/nfd-master.md
View file

@ -97,5 +97,5 @@ in bigger clusters.
If you have RBAC authorization enabled (as is the default e.g. with 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, 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. labels. The provided template will configure these for you.