apis/nfd: add matchName field in feature matcher terms

[marquiz]

Extend NodeFeatureRule API

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"]}

Sample rules

This PR contains also another patch that 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/

[marquiz]

Still a POC/RFC, missing e.g. documentation
/hold

[ArangoGutierrez]

still a hold?

[marquiz]

still a hold?

Heh, I'm still a bit unsure do we need this, if anybody wants this 😄 OTOH, it would make it possible to turn all "built-in" labels into NodeFeatureRules 🧐

In addition, docs are still missing.

[marquiz]

/retest

[marquiz]

Rebased

[netlify]

✅ Deploy Preview for kubernetes-sigs-nfd ready!

Name	Link
🔨 Latest commit	49886ed
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-nfd/deploys/657c1d4ea48f910008af4ab5
😎 Deploy Preview	https://deploy-preview-788--kubernetes-sigs-nfd.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[marquiz]

Update:

• rebased
• fixed a bug where the matchNames never failed
• added e2e tests

I think this would be ready for review, no reason to keep it hanging open forever. At least should not have any effect (cause problems) if not used 😉
/unhold

[marquiz]

/assign @ArangoGutierrez

[marquiz]

Ach, docs is missing 🙈 (plus unit tests fail)
/hold

[marquiz]

Rebased. Added documentation.
/unhold

[ArangoGutierrez]

with this Samples, should we remove examples ?

[marquiz]

It is a good question where we should put these 🤔 The examples/ are really supposed to be examples but these are "fully usable" samples that replicate the built-in labels. Maybe these should be put somewhere under deployment/ instead, e.g. deployment/nodefeaturerule/. Any thoughts?

[ArangoGutierrez]

I like deployment/nodefeaturerule/samples

[marquiz]

Let's do that, then. Better I think

[ArangoGutierrez]

/retest

[ArangoGutierrez]

/needs-rebase

[ArangoGutierrez]

v0.15 here we gooo!
/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 4714b3d1701ce3b7624f3ff116fc7e8d584dcaea

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ArangoGutierrez, marquiz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ArangoGutierrez,marquiz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[marquiz]

/hold

[codecov]

Codecov Report

Merging #788 (49886ed) into master (443ff80) will decrease coverage by 0.07%.
The diff coverage is 34.25%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #788      +/-   ##
==========================================
- Coverage   31.39%   31.33%   -0.07%     
==========================================
  Files          59       59              
  Lines        7555     7647      +92     
==========================================
+ Hits         2372     2396      +24     
- Misses       4939     5001      +62     
- Partials      244      250       +6     

Files	Coverage Δ
pkg/apis/nfd/v1alpha1/zz_generated.deepcopy.go	26.14% <57.89%> (+0.25%)	⬆️
pkg/apis/nfd/v1alpha1/rule.go	78.12% <64.28%> (-2.95%)	⬇️
pkg/apis/nfd/v1alpha1/expression.go	66.66% <13.11%> (-10.12%)	⬇️

[marquiz]

Too slow 😿

[marquiz]

OK, see #1504