1
0
Fork 0
mirror of https://github.com/kubernetes-sigs/node-feature-discovery.git synced 2024-12-14 11:57:51 +00:00

Fix a couple typos

Signed-off-by: Carlos Eduardo Arango Gutierrez <carangog@redhat.com>
This commit is contained in:
Carlos Eduardo Arango Gutierrez 2022-03-23 19:15:22 -04:00
parent 2b2271120f
commit 73d874b92f
No known key found for this signature in database
GPG key ID: A9596BE502663DFD
4 changed files with 5 additions and 5 deletions

View file

@ -18,7 +18,7 @@ Please do not remove items from the checklist
- [ ] An OWNER pushes the new release branch with
`git push release-0.$MAJ`
- [ ] Run `scripts/prepare-release.sh $VERSION` to turn references to point to the upcoming release
(README, deployment templates, docs configuration, test/e2e flags), submit a PR agains the release branch
(README, deployment templates, docs configuration, test/e2e flags), submit a PR against the release branch
- An OWNER prepares a draft release
- [ ] Create a draft release at [Github releases page](https://github.com/kubernetes-sigs/node-feature-discovery/releases)
- [ ] Write the change log into the draft release

View file

@ -710,7 +710,7 @@ Consider the following configuration:
The `feature.node.kubernetes.io/high-level-feature = true` label depends on thw
two previous rules.
Note that when referencing rules accross multiple
Note that when referencing rules across multiple
[`NodeFeatureRule`](#nodefeaturerule-custom-resource) objects attention must be
paid to the ordering. `NodeFeatureRule` objects are processed in alphabetical
order (based on their `.metadata.name`).

View file

@ -66,7 +66,7 @@ make push-all
```
The resulting container image can be used in the same way on each arch by pulling
e.g. `node-feature-discovery:v0.10.0` without specifying the architechture. The
e.g. `node-feature-discovery:v0.10.0` without specifying the architecture. The
manifest-list will take care of providing the right architecture image.
#### Change the job spec to use your custom image (optional)

View file

@ -116,7 +116,7 @@ scenarios under
[`deployment/overlays`](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/overlays)
- [`default`](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/overlays/default):
default deployment of nfd-worker as a daemonset, descibed above
default deployment of nfd-worker as a daemonset, described above
- [`default-combined`](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/overlays/default-combined)
see [Master-worker pod](#master-worker-pod) below
- [`default-job`](https://github.com/kubernetes-sigs/node-feature-discovery/blob/{{site.release}}/deployment/overlays/default-job):
@ -340,7 +340,7 @@ We have introduced the following Chart parameters.
| `topologyUpdater.serviceAccount.create` | bool | true | Specifies whether the service account for topology updater should be created |
| `topologyUpdater.serviceAccount.annotations` | dict | {} | Annotations to add to the service account for topology updater |
| `topologyUpdater.serviceAccount.name` | string | | The name of the service account for topology updater to use. If not set and create is true, a name is generated using the fullname template and `-topology-updater` suffix |
| `topologyUpdater.rbac` | dict | | RBAC [parameteres](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) for the topology updater |
| `topologyUpdater.rbac` | dict | | RBAC [parameters](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) for the topology updater |
| `topologyUpdater.rbac.create` | bool | false | Specifies whether the cluster role and binding for topology updater should be created |
| `topologyUpdater.kubeletConfigPath` | string | "" | Specifies the kubelet config host path |
| `topologyUpdater.kubeletPodResourcesSockPath` | string | "" | Specifies the kubelet sock path to read pod resources |