Change the custom feature source of nfd-worker to use the newly added
internal config API for its own configuration. It now uses the internal
types for json/yaml unmarshalling but converts them to external
nfdv1alpha1 API to do the actual rule matching as the internal API does
not duplicate that functionality.
Add internal API for the nfd-worker custom feature source rule
configuration. This API has already diverged from the NFD
NodeFeatureRule API in that annotations, extended resources or taints
are not supported. This patch basically copies the Rule type (and it's
sub-types) from the nfdv1alpha1 package. It also adds conversion
functions from the internal rule API to the "external" nfdv1alpha1 API.
This is done to use the same rule matching functionality (from the
nfdv1alpha1 package).
One notable remark is that the feature source rule config supports some
custom formatting (short forms, multi-type fields) that relies on
special json/yaml unmarshalling functions that are better to nuke from
the nfdv1alpha1 package (in another patch). These (legacy) syntax
specialities are most probably used by nobody but let's keep them as
they're already there. Unit tests to cover the custom json
unmarshalling are now added.
This patch adds sample NodeFeatureRules that correspond the built-in
labels created by nfd-worker (with its default configuration).
The samples provide examples on how to utilize NodeFeatureRules and an
easy way to modify the labels being generated. In order to replace the
built-in node labeling of nfd-worker with these sample rules, all node
labeling from nfd-worker must be disabled by setting the
"core.labelSources" configuration option to an empty list (or specify
"-label-sources= " on the command line). Then, with all nfd-worker side
labeling disabled, just apply the rules with
kubectl apply -f samples/
Extend the format of feature matcher terms (the elements of the
arrayspecified under under matchFeatures field) with new matchName
field. The value of this field is an expression that is evaluated
against the names of feature elements instead of their values (values
are matched with the matchExpressions field, instead).
The matchName field is useful e.g. in template rules for creating
per-feature-element labels based on feature names (instead of values)
and in non-template rules for checking if (at least) one of certain
feature element names are present.
If both matchExpressions and matchName for certain feature matcher term
is specified, they both must match in order to get an overall match.
Also, in this case the list of matched features (used in templating) is
the union of the results from matchExpressions and matchName.
An example of creating an "avx512" label if any AVX512* CPUID feature is
present:
- name: "avx wildcard rule"
labels:
avx512: "true"
matchFeatures:
- feature: cpu.cpuid
matchName: {op: InRegexp, value: ["^AVX512"]}
An example of a template rule creating a dynamic set of labels based on
the existence of certain kconfig options.
- name: "kconfig template rule"
labelsTemplate: |
{{ range .kernel.config }}kconfig-{{ .Name }}={{ .Value }}
{{ end }}
matchFeatures:
- feature: kernel.config
matchName: {op: In, value: ["SWAP", "X86", "ARM"]}
NOTE: this patch changes the corner case of nil/null match expressions
with instance features (i.e. "matchExpressions: null"). Previously, we
returned all instances for templating but now a nil match expression is
not evaluated and no instances for templating are returned.
