2020-11-27 10:19:31 +02:00
|
|
|
#core:
|
2020-12-01 14:54:59 +02:00
|
|
|
# labelWhiteList:
|
2020-11-27 10:19:31 +02:00
|
|
|
# noPublish: false
|
2020-12-01 14:27:47 +02:00
|
|
|
# sleepInterval: 60s
|
2021-08-27 12:52:24 +03:00
|
|
|
# featureSources: [all]
|
2021-11-25 10:58:08 +02:00
|
|
|
# labelSources: [all]
|
2021-02-23 20:42:17 +02:00
|
|
|
# klog:
|
|
|
|
# addDirHeader: false
|
|
|
|
# alsologtostderr: false
|
|
|
|
# logBacktraceAt:
|
|
|
|
# logtostderr: true
|
|
|
|
# skipHeaders: false
|
|
|
|
# stderrthreshold: 2
|
|
|
|
# v: 0
|
|
|
|
# vmodule:
|
|
|
|
## NOTE: the following options are not dynamically run-time configurable
|
|
|
|
## and require a nfd-worker restart to take effect after being changed
|
|
|
|
# logDir:
|
|
|
|
# logFile:
|
|
|
|
# logFileMaxSize: 1800
|
|
|
|
# skipLogHeaders: false
|
2018-07-06 14:11:07 +03:00
|
|
|
#sources:
|
2019-05-13 17:10:55 +03:00
|
|
|
# cpu:
|
|
|
|
# cpuid:
|
|
|
|
## NOTE: whitelist has priority over blacklist
|
|
|
|
# attributeBlacklist:
|
|
|
|
# - "BMI1"
|
|
|
|
# - "BMI2"
|
|
|
|
# - "CLMUL"
|
|
|
|
# - "CMOV"
|
|
|
|
# - "CX16"
|
|
|
|
# - "ERMS"
|
|
|
|
# - "F16C"
|
|
|
|
# - "HTT"
|
|
|
|
# - "LZCNT"
|
|
|
|
# - "MMX"
|
|
|
|
# - "MMXEXT"
|
|
|
|
# - "NX"
|
|
|
|
# - "POPCNT"
|
|
|
|
# - "RDRAND"
|
|
|
|
# - "RDSEED"
|
|
|
|
# - "RDTSCP"
|
|
|
|
# - "SGX"
|
|
|
|
# - "SSE"
|
|
|
|
# - "SSE2"
|
|
|
|
# - "SSE3"
|
2021-07-06 11:54:55 +03:00
|
|
|
# - "SSE4"
|
|
|
|
# - "SSE42"
|
2019-05-13 17:10:55 +03:00
|
|
|
# - "SSSE3"
|
2023-06-02 11:01:10 +02:00
|
|
|
# - "TDX_GUEST"
|
2019-05-13 17:10:55 +03:00
|
|
|
# attributeWhitelist:
|
2018-07-06 14:11:07 +03:00
|
|
|
# kernel:
|
|
|
|
# kconfigFile: "/path/to/kconfig"
|
|
|
|
# configOpts:
|
|
|
|
# - "NO_HZ"
|
|
|
|
# - "X86"
|
|
|
|
# - "DMI"
|
2018-09-21 13:25:47 +03:00
|
|
|
# pci:
|
|
|
|
# deviceClassWhitelist:
|
|
|
|
# - "0200"
|
|
|
|
# - "03"
|
|
|
|
# - "12"
|
2018-09-21 15:16:41 +03:00
|
|
|
# deviceLabelFields:
|
|
|
|
# - "class"
|
|
|
|
# - "vendor"
|
|
|
|
# - "device"
|
|
|
|
# - "subsystem_vendor"
|
|
|
|
# - "subsystem_device"
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 22:32:55 +02:00
|
|
|
# usb:
|
|
|
|
# deviceClassWhitelist:
|
|
|
|
# - "0e"
|
|
|
|
# - "ef"
|
|
|
|
# - "fe"
|
|
|
|
# - "ff"
|
|
|
|
# deviceLabelFields:
|
|
|
|
# - "class"
|
|
|
|
# - "vendor"
|
|
|
|
# - "device"
|
2022-08-22 13:46:14 +03:00
|
|
|
# local:
|
2023-04-24 14:35:26 +03:00
|
|
|
# hooksEnabled: false
|
2020-02-16 18:36:38 +02:00
|
|
|
# custom:
|
source/custom: implement generic feature matching
Implement generic feature matchers that cover all feature sources (that
implement the FeatureSource interface). The implementation relies on the
unified data model provided by the FeatureSource interface as well as
the generic expression-based rule processing framework that was added to
the source/custom/expression package.
With this patch any new features added will be automatically available
for custom rules, without any additional work. Rule hierarchy follows
the source/feature hierarchy by design.
This patch introduces a new format for custom rule specifications,
dropping the 'value' field and introducing new 'labels' field which
makes it possible to specify multiple labels per rule. Also, in the new
format the 'name' field is just for reference and no matching label is
created. The new generic rules are available in this new rule format
under a 'matchFeatures. MatchFeatures implements a logical AND over
an array of per-feature matchers - i.e. a match for all of the matchers
is required. The goal of the new rule format is to make it better follow
K8s API design guidelines and make it extensible for future enhancements
(e.g. addition of templating, taints, annotations, extended resources
etc).
The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID,
usbID rules) is still supported. The rule format (new vs. old) is
determined at config parsing time based on the existence of the
'matchOn' field.
The new rule format and the configuration format for the new
matchFeatures field is
- name: <rule-name>
labels:
<key>: <value>
...
matchFeatures:
- feature: <domain>.<feature>
matchExpressions:
<attribute>:
op: <operator>
value:
- <list-of-values>
- feature: <domain>.<feature>
...
Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources
are covered by the matshers/feature selectors. Thus, the following
features are available for matching with this patch:
- cpu.cpuid:
<cpuid-flag>: <exists/does-not-exist>
- cpu.cstate:
enabled: <bool>
- cpu.pstate:
status: <string>
turbo: <bool>
scaling_governor: <string>
- cpu.rdt:
<rdt-feature>: <exists/does-not-exist>
- cpu.sst:
bf.enabled: <bool>
- cpu.topology:
hardware_multithreading: <bool>
- kernel.config:
<flag-name>: <string>
- kernel.loadedmodule:
<module-name>: <exists/does-not-exist>
- kernel.selinux:
enabled: <bool>
- kernel.version:
major: <int>
minor: <int>
revision: <int>
full: <string>
- system.osrelease:
<key-name>: <string>
VERSION_ID.major: <int>
VERSION_ID.minor: <int>
- system.name:
nodename: <string>
- pci.device:
<device-instance>:
class: <string>
vendor: <string>
device: <string>
subsystem_vendor: <string>
susbystem_device: <string>
sriov_totalvfs: <int>
- usb.device:
<device-instance>:
class: <string>
vendor: <string>
device: <string>
serial: <string>
- local.label:
<label-name>: <string>
The configuration also supports some "shortforms" for convenience:
matchExpressions: [<attr-1>, <attr-2>=<val-2>]
---
matchExpressions:
<attr-3>:
<attr-4>: <val-4>
is equal to:
matchExpressions:
<attr-1>: {op: Exists}
<attr-2>: {op: In, value: [<val-2>]}
---
matchExpressions:
<attr-3>: {op: Exists}
<attr-4>: {op: In, value: [<val-4>]}
In other words:
- feature: kernel.config
matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"]
- feature: pci.device
matchExpressions:
vendor: "8086"
is the same as:
- feature: kernel.config
matchExpressions:
X86: {op: Exists}
INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]}
- feature: pci.device
matchExpressions:
vendor: {op: In, value: ["8086"]
Some configuration examples below. In order to match a CPUID feature the
following snippet can be used:
- name: cpu-test-1
labels:
cpu-custom-feature: "true"
matchFeatures:
- feature: cpu.cpuid
matchExpressions:
AESNI: {op: Exists}
AVX: {op: Exists}
In order to match against a loaded kernel module and OS version:
- name: kernel-test-1
labels:
kernel-custom-feature: "true"
matchFeatures:
- feature: kernel.loadedmodule
matchExpressions:
e1000: {op: Exists}
- feature: system.osrelease
matchExpressions:
NAME: {op: InRegexp, values: ["^openSUSE"]}
VERSION_ID.major: {op: Gt, values: ["14"]}
In order to require a kernel module and both of two specific PCI devices:
- name: multi-device-test
labels:
multi-device-feature: "true"
matchFeatures:
- feature: kernel.loadedmodule
matchExpressions:
driver-module: {op: Exists}
- pci.device:
vendor: "8086"
device: "1234"
- pci.device:
vendor: "8086"
device: "abcd"
2021-10-14 10:22:07 +03:00
|
|
|
# # The following feature demonstrates the capabilities of the matchFeatures
|
2021-12-13 14:19:36 +02:00
|
|
|
# - name: "my custom rule"
|
source/custom: implement generic feature matching
Implement generic feature matchers that cover all feature sources (that
implement the FeatureSource interface). The implementation relies on the
unified data model provided by the FeatureSource interface as well as
the generic expression-based rule processing framework that was added to
the source/custom/expression package.
With this patch any new features added will be automatically available
for custom rules, without any additional work. Rule hierarchy follows
the source/feature hierarchy by design.
This patch introduces a new format for custom rule specifications,
dropping the 'value' field and introducing new 'labels' field which
makes it possible to specify multiple labels per rule. Also, in the new
format the 'name' field is just for reference and no matching label is
created. The new generic rules are available in this new rule format
under a 'matchFeatures. MatchFeatures implements a logical AND over
an array of per-feature matchers - i.e. a match for all of the matchers
is required. The goal of the new rule format is to make it better follow
K8s API design guidelines and make it extensible for future enhancements
(e.g. addition of templating, taints, annotations, extended resources
etc).
The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID,
usbID rules) is still supported. The rule format (new vs. old) is
determined at config parsing time based on the existence of the
'matchOn' field.
The new rule format and the configuration format for the new
matchFeatures field is
- name: <rule-name>
labels:
<key>: <value>
...
matchFeatures:
- feature: <domain>.<feature>
matchExpressions:
<attribute>:
op: <operator>
value:
- <list-of-values>
- feature: <domain>.<feature>
...
Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources
are covered by the matshers/feature selectors. Thus, the following
features are available for matching with this patch:
- cpu.cpuid:
<cpuid-flag>: <exists/does-not-exist>
- cpu.cstate:
enabled: <bool>
- cpu.pstate:
status: <string>
turbo: <bool>
scaling_governor: <string>
- cpu.rdt:
<rdt-feature>: <exists/does-not-exist>
- cpu.sst:
bf.enabled: <bool>
- cpu.topology:
hardware_multithreading: <bool>
- kernel.config:
<flag-name>: <string>
- kernel.loadedmodule:
<module-name>: <exists/does-not-exist>
- kernel.selinux:
enabled: <bool>
- kernel.version:
major: <int>
minor: <int>
revision: <int>
full: <string>
- system.osrelease:
<key-name>: <string>
VERSION_ID.major: <int>
VERSION_ID.minor: <int>
- system.name:
nodename: <string>
- pci.device:
<device-instance>:
class: <string>
vendor: <string>
device: <string>
subsystem_vendor: <string>
susbystem_device: <string>
sriov_totalvfs: <int>
- usb.device:
<device-instance>:
class: <string>
vendor: <string>
device: <string>
serial: <string>
- local.label:
<label-name>: <string>
The configuration also supports some "shortforms" for convenience:
matchExpressions: [<attr-1>, <attr-2>=<val-2>]
---
matchExpressions:
<attr-3>:
<attr-4>: <val-4>
is equal to:
matchExpressions:
<attr-1>: {op: Exists}
<attr-2>: {op: In, value: [<val-2>]}
---
matchExpressions:
<attr-3>: {op: Exists}
<attr-4>: {op: In, value: [<val-4>]}
In other words:
- feature: kernel.config
matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"]
- feature: pci.device
matchExpressions:
vendor: "8086"
is the same as:
- feature: kernel.config
matchExpressions:
X86: {op: Exists}
INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]}
- feature: pci.device
matchExpressions:
vendor: {op: In, value: ["8086"]
Some configuration examples below. In order to match a CPUID feature the
following snippet can be used:
- name: cpu-test-1
labels:
cpu-custom-feature: "true"
matchFeatures:
- feature: cpu.cpuid
matchExpressions:
AESNI: {op: Exists}
AVX: {op: Exists}
In order to match against a loaded kernel module and OS version:
- name: kernel-test-1
labels:
kernel-custom-feature: "true"
matchFeatures:
- feature: kernel.loadedmodule
matchExpressions:
e1000: {op: Exists}
- feature: system.osrelease
matchExpressions:
NAME: {op: InRegexp, values: ["^openSUSE"]}
VERSION_ID.major: {op: Gt, values: ["14"]}
In order to require a kernel module and both of two specific PCI devices:
- name: multi-device-test
labels:
multi-device-feature: "true"
matchFeatures:
- feature: kernel.loadedmodule
matchExpressions:
driver-module: {op: Exists}
- pci.device:
vendor: "8086"
device: "1234"
- pci.device:
vendor: "8086"
device: "abcd"
2021-10-14 10:22:07 +03:00
|
|
|
# labels:
|
|
|
|
# my-ng-feature: "true"
|
|
|
|
# # matchFeatures implements a logical AND over all matcher terms in the
|
|
|
|
# # list (i.e. all of the terms, or per-feature matchers, must match)
|
|
|
|
# matchFeatures:
|
|
|
|
# - feature: cpu.cpuid
|
|
|
|
# matchExpressions:
|
|
|
|
# AVX512F: {op: Exists}
|
|
|
|
# - feature: cpu.cstate
|
|
|
|
# matchExpressions:
|
|
|
|
# enabled: {op: IsTrue}
|
|
|
|
# - feature: cpu.pstate
|
|
|
|
# matchExpressions:
|
|
|
|
# no_turbo: {op: IsFalse}
|
|
|
|
# scaling_governor: {op: In, value: ["performance"]}
|
|
|
|
# - feature: cpu.rdt
|
|
|
|
# matchExpressions:
|
|
|
|
# RDTL3CA: {op: Exists}
|
|
|
|
# - feature: cpu.sst
|
|
|
|
# matchExpressions:
|
|
|
|
# bf.enabled: {op: IsTrue}
|
|
|
|
# - feature: cpu.topology
|
|
|
|
# matchExpressions:
|
|
|
|
# hardware_multithreading: {op: IsFalse}
|
|
|
|
#
|
|
|
|
# - feature: kernel.config
|
|
|
|
# matchExpressions:
|
|
|
|
# X86: {op: Exists}
|
|
|
|
# LSM: {op: InRegexp, value: ["apparmor"]}
|
|
|
|
# - feature: kernel.loadedmodule
|
|
|
|
# matchExpressions:
|
|
|
|
# e1000e: {op: Exists}
|
|
|
|
# - feature: kernel.selinux
|
|
|
|
# matchExpressions:
|
|
|
|
# enabled: {op: IsFalse}
|
|
|
|
# - feature: kernel.version
|
|
|
|
# matchExpressions:
|
|
|
|
# major: {op: In, value: ["5"]}
|
|
|
|
# minor: {op: Gt, value: ["10"]}
|
|
|
|
#
|
2021-11-23 10:00:34 +02:00
|
|
|
# - feature: storage.block
|
|
|
|
# matchExpressions:
|
2021-06-24 20:35:34 +03:00
|
|
|
# rotational: {op: In, value: ["0"]}
|
|
|
|
# dax: {op: In, value: ["0"]}
|
|
|
|
#
|
2021-06-24 22:57:46 +03:00
|
|
|
# - feature: network.device
|
|
|
|
# matchExpressions:
|
|
|
|
# operstate: {op: In, value: ["up"]}
|
|
|
|
# speed: {op: Gt, value: ["100"]}
|
|
|
|
#
|
2021-08-25 19:37:32 +03:00
|
|
|
# - feature: memory.numa
|
|
|
|
# matchExpressions:
|
|
|
|
# node_count: {op: Gt, value: ["2"]}
|
|
|
|
# - feature: memory.nv
|
|
|
|
# matchExpressions:
|
|
|
|
# devtype: {op: In, value: ["nd_dax"]}
|
|
|
|
# mode: {op: In, value: ["memory"]}
|
|
|
|
#
|
source/custom: implement generic feature matching
Implement generic feature matchers that cover all feature sources (that
implement the FeatureSource interface). The implementation relies on the
unified data model provided by the FeatureSource interface as well as
the generic expression-based rule processing framework that was added to
the source/custom/expression package.
With this patch any new features added will be automatically available
for custom rules, without any additional work. Rule hierarchy follows
the source/feature hierarchy by design.
This patch introduces a new format for custom rule specifications,
dropping the 'value' field and introducing new 'labels' field which
makes it possible to specify multiple labels per rule. Also, in the new
format the 'name' field is just for reference and no matching label is
created. The new generic rules are available in this new rule format
under a 'matchFeatures. MatchFeatures implements a logical AND over
an array of per-feature matchers - i.e. a match for all of the matchers
is required. The goal of the new rule format is to make it better follow
K8s API design guidelines and make it extensible for future enhancements
(e.g. addition of templating, taints, annotations, extended resources
etc).
The old rule format (with cpuID, kConfig, loadedKMod, nodename, pciID,
usbID rules) is still supported. The rule format (new vs. old) is
determined at config parsing time based on the existence of the
'matchOn' field.
The new rule format and the configuration format for the new
matchFeatures field is
- name: <rule-name>
labels:
<key>: <value>
...
matchFeatures:
- feature: <domain>.<feature>
matchExpressions:
<attribute>:
op: <operator>
value:
- <list-of-values>
- feature: <domain>.<feature>
...
Currently, "cpu", "kernel", "pci", "system", "usb" and "local" sources
are covered by the matshers/feature selectors. Thus, the following
features are available for matching with this patch:
- cpu.cpuid:
<cpuid-flag>: <exists/does-not-exist>
- cpu.cstate:
enabled: <bool>
- cpu.pstate:
status: <string>
turbo: <bool>
scaling_governor: <string>
- cpu.rdt:
<rdt-feature>: <exists/does-not-exist>
- cpu.sst:
bf.enabled: <bool>
- cpu.topology:
hardware_multithreading: <bool>
- kernel.config:
<flag-name>: <string>
- kernel.loadedmodule:
<module-name>: <exists/does-not-exist>
- kernel.selinux:
enabled: <bool>
- kernel.version:
major: <int>
minor: <int>
revision: <int>
full: <string>
- system.osrelease:
<key-name>: <string>
VERSION_ID.major: <int>
VERSION_ID.minor: <int>
- system.name:
nodename: <string>
- pci.device:
<device-instance>:
class: <string>
vendor: <string>
device: <string>
subsystem_vendor: <string>
susbystem_device: <string>
sriov_totalvfs: <int>
- usb.device:
<device-instance>:
class: <string>
vendor: <string>
device: <string>
serial: <string>
- local.label:
<label-name>: <string>
The configuration also supports some "shortforms" for convenience:
matchExpressions: [<attr-1>, <attr-2>=<val-2>]
---
matchExpressions:
<attr-3>:
<attr-4>: <val-4>
is equal to:
matchExpressions:
<attr-1>: {op: Exists}
<attr-2>: {op: In, value: [<val-2>]}
---
matchExpressions:
<attr-3>: {op: Exists}
<attr-4>: {op: In, value: [<val-4>]}
In other words:
- feature: kernel.config
matchExpressions: ["X86", "INIT_ENV_ARG_LIMIT=32"]
- feature: pci.device
matchExpressions:
vendor: "8086"
is the same as:
- feature: kernel.config
matchExpressions:
X86: {op: Exists}
INIT_ENV_ARG_LIMIT: {op: In, values: ["32"]}
- feature: pci.device
matchExpressions:
vendor: {op: In, value: ["8086"]
Some configuration examples below. In order to match a CPUID feature the
following snippet can be used:
- name: cpu-test-1
labels:
cpu-custom-feature: "true"
matchFeatures:
- feature: cpu.cpuid
matchExpressions:
AESNI: {op: Exists}
AVX: {op: Exists}
In order to match against a loaded kernel module and OS version:
- name: kernel-test-1
labels:
kernel-custom-feature: "true"
matchFeatures:
- feature: kernel.loadedmodule
matchExpressions:
e1000: {op: Exists}
- feature: system.osrelease
matchExpressions:
NAME: {op: InRegexp, values: ["^openSUSE"]}
VERSION_ID.major: {op: Gt, values: ["14"]}
In order to require a kernel module and both of two specific PCI devices:
- name: multi-device-test
labels:
multi-device-feature: "true"
matchFeatures:
- feature: kernel.loadedmodule
matchExpressions:
driver-module: {op: Exists}
- pci.device:
vendor: "8086"
device: "1234"
- pci.device:
vendor: "8086"
device: "abcd"
2021-10-14 10:22:07 +03:00
|
|
|
# - feature: system.osrelease
|
|
|
|
# matchExpressions:
|
|
|
|
# ID: {op: In, value: ["fedora", "centos"]}
|
|
|
|
# - feature: system.name
|
|
|
|
# matchExpressions:
|
|
|
|
# nodename: {op: InRegexp, value: ["^worker-X"]}
|
|
|
|
#
|
|
|
|
# - feature: local.label
|
|
|
|
# matchExpressions:
|
|
|
|
# custom-feature-knob: {op: Gt, value: ["100"]}
|
2021-03-04 12:39:42 +02:00
|
|
|
#
|
|
|
|
# # The following feature demonstrates the capabilities of the matchAny
|
2021-12-13 14:19:36 +02:00
|
|
|
# - name: "my matchAny rule"
|
2021-03-04 12:39:42 +02:00
|
|
|
# labels:
|
|
|
|
# my-ng-feature-2: "my-value"
|
|
|
|
# # matchAny implements a logical IF over all elements (sub-matchers) in
|
|
|
|
# # the list (i.e. at least one feature matcher must match)
|
|
|
|
# matchAny:
|
|
|
|
# - matchFeatures:
|
|
|
|
# - feature: kernel.loadedmodule
|
|
|
|
# matchExpressions:
|
|
|
|
# driver-module-X: {op: Exists}
|
|
|
|
# - feature: pci.device
|
|
|
|
# matchExpressions:
|
|
|
|
# vendor: {op: In, value: ["8086"]}
|
|
|
|
# class: {op: In, value: ["0200"]}
|
|
|
|
# - matchFeatures:
|
|
|
|
# - feature: kernel.loadedmodule
|
|
|
|
# matchExpressions:
|
|
|
|
# driver-module-Y: {op: Exists}
|
|
|
|
# - feature: usb.device
|
|
|
|
# matchExpressions:
|
|
|
|
# vendor: {op: In, value: ["8086"]}
|
|
|
|
# class: {op: In, value: ["02"]}
|
pkg/apis/nfd: support label name templating
Support templating of label names in feature rules. It is available both
in NodeFeatureRule CRs and in custom rule configuration of nfd-worker.
This patch adds a new 'labelsTemplate' field to the rule spec, making it
possible to dynamically generate multiple labels per rule based on the
matched features. The feature relies on the golang "text/template"
package. When expanded, the template must contain labels in a raw
<key>[=<value>] format (where 'value' defaults to "true"), separated by
newlines i.e.:
- name: <rule-name>
labelsTemplate: |
<label-1>[=<value-1>]
<label-2>[=<value-2>]
...
All the matched features of 'matchFeatures' directives are available for
templating engine in a nested data structure that can be described in
yaml as:
.
<domain-1>:
<key-feature-1>:
- Name: <matched-key>
- ...
<value-feature-1:
- Name: <matched-key>
Value: <matched-value>
- ...
<instance-feature-1>:
- <attribute-1-name>: <attribute-1-value>
<attribute-2-name>: <attribute-2-value>
...
- ...
<domain-2>:
...
That is, the per-feature data available for matching depends on the type
of feature that was matched:
- "key features": only 'Name' is available
- "value features": 'Name' and 'Value' can be used
- "instance features": all attributes of the matched instance are
available
NOTE: In case of matchAny is specified, the template is executed
separately against each individual matchFeatures matcher and the
eventual set of labels is a superset of all these expansions. Consider
the following:
- name: <name>
labelsTemplate: <template>
matchAny:
- matchFeatures: <matcher#1>
- matchFeatures: <matcher#2>
matchFeatures: <matcher#3>
In the example above (assuming the overall result is a match) the
template would be executed on matcher#1 and/or matcher#2 (depending on
whether both or only one of them match), and finally on matcher#3, and
all the labels from these separate expansions would be created (i.e. the
end result would be a union of all the individual expansions).
NOTE 2: The 'labels' field has priority over 'labelsTemplate', i.e.
labels specified in the 'labels' field will override any labels
originating from the 'labelsTemplate' field.
A special case of an empty match expression set matches everything (i.e.
matches/returns all existing keys/values). This makes it simpler to
write templates that run over all values. Also, makes it possible to
later implement support for templates that run over all _keys_ of a
feature.
Some example configurations:
- name: "my-pci-template-features"
labelsTemplate: |
{{ range .pci.device }}intel-{{ .class }}-{{ .device }}=present
{{ end }}
matchFeatures:
- feature: pci.device
matchExpressions:
class: {op: InRegexp, value: ["^06"]}
vendor: ["8086"]
- name: "my-system-template-features"
labelsTemplate: |
{{ range .system.osrelease }}system-{{ .Name }}={{ .Value }}
{{ end }}
matchFeatures:
- feature: system.osRelease
matchExpressions:
ID: {op: Exists}
VERSION_ID.major: {op: Exists}
Imaginative template pipelines are possible, of course, but care must be
taken in order to produce understandable and maintainable rule sets.
2021-05-04 16:30:06 +03:00
|
|
|
#
|
|
|
|
# # The following features demonstreate label templating capabilities
|
2021-12-13 14:19:36 +02:00
|
|
|
# - name: "my template rule"
|
pkg/apis/nfd: support label name templating
Support templating of label names in feature rules. It is available both
in NodeFeatureRule CRs and in custom rule configuration of nfd-worker.
This patch adds a new 'labelsTemplate' field to the rule spec, making it
possible to dynamically generate multiple labels per rule based on the
matched features. The feature relies on the golang "text/template"
package. When expanded, the template must contain labels in a raw
<key>[=<value>] format (where 'value' defaults to "true"), separated by
newlines i.e.:
- name: <rule-name>
labelsTemplate: |
<label-1>[=<value-1>]
<label-2>[=<value-2>]
...
All the matched features of 'matchFeatures' directives are available for
templating engine in a nested data structure that can be described in
yaml as:
.
<domain-1>:
<key-feature-1>:
- Name: <matched-key>
- ...
<value-feature-1:
- Name: <matched-key>
Value: <matched-value>
- ...
<instance-feature-1>:
- <attribute-1-name>: <attribute-1-value>
<attribute-2-name>: <attribute-2-value>
...
- ...
<domain-2>:
...
That is, the per-feature data available for matching depends on the type
of feature that was matched:
- "key features": only 'Name' is available
- "value features": 'Name' and 'Value' can be used
- "instance features": all attributes of the matched instance are
available
NOTE: In case of matchAny is specified, the template is executed
separately against each individual matchFeatures matcher and the
eventual set of labels is a superset of all these expansions. Consider
the following:
- name: <name>
labelsTemplate: <template>
matchAny:
- matchFeatures: <matcher#1>
- matchFeatures: <matcher#2>
matchFeatures: <matcher#3>
In the example above (assuming the overall result is a match) the
template would be executed on matcher#1 and/or matcher#2 (depending on
whether both or only one of them match), and finally on matcher#3, and
all the labels from these separate expansions would be created (i.e. the
end result would be a union of all the individual expansions).
NOTE 2: The 'labels' field has priority over 'labelsTemplate', i.e.
labels specified in the 'labels' field will override any labels
originating from the 'labelsTemplate' field.
A special case of an empty match expression set matches everything (i.e.
matches/returns all existing keys/values). This makes it simpler to
write templates that run over all values. Also, makes it possible to
later implement support for templates that run over all _keys_ of a
feature.
Some example configurations:
- name: "my-pci-template-features"
labelsTemplate: |
{{ range .pci.device }}intel-{{ .class }}-{{ .device }}=present
{{ end }}
matchFeatures:
- feature: pci.device
matchExpressions:
class: {op: InRegexp, value: ["^06"]}
vendor: ["8086"]
- name: "my-system-template-features"
labelsTemplate: |
{{ range .system.osrelease }}system-{{ .Name }}={{ .Value }}
{{ end }}
matchFeatures:
- feature: system.osRelease
matchExpressions:
ID: {op: Exists}
VERSION_ID.major: {op: Exists}
Imaginative template pipelines are possible, of course, but care must be
taken in order to produce understandable and maintainable rule sets.
2021-05-04 16:30:06 +03:00
|
|
|
# labelsTemplate: |
|
|
|
|
# {{ range .system.osrelease }}my-system-feature.{{ .Name }}={{ .Value }}
|
|
|
|
# {{ end }}
|
|
|
|
# matchFeatures:
|
|
|
|
# - feature: system.osrelease
|
|
|
|
# matchExpressions:
|
|
|
|
# ID: {op: InRegexp, value: ["^open.*"]}
|
|
|
|
# VERSION_ID.major: {op: In, value: ["13", "15"]}
|
|
|
|
#
|
2021-12-13 14:19:36 +02:00
|
|
|
# - name: "my template rule 2"
|
pkg/apis/nfd: support label name templating
Support templating of label names in feature rules. It is available both
in NodeFeatureRule CRs and in custom rule configuration of nfd-worker.
This patch adds a new 'labelsTemplate' field to the rule spec, making it
possible to dynamically generate multiple labels per rule based on the
matched features. The feature relies on the golang "text/template"
package. When expanded, the template must contain labels in a raw
<key>[=<value>] format (where 'value' defaults to "true"), separated by
newlines i.e.:
- name: <rule-name>
labelsTemplate: |
<label-1>[=<value-1>]
<label-2>[=<value-2>]
...
All the matched features of 'matchFeatures' directives are available for
templating engine in a nested data structure that can be described in
yaml as:
.
<domain-1>:
<key-feature-1>:
- Name: <matched-key>
- ...
<value-feature-1:
- Name: <matched-key>
Value: <matched-value>
- ...
<instance-feature-1>:
- <attribute-1-name>: <attribute-1-value>
<attribute-2-name>: <attribute-2-value>
...
- ...
<domain-2>:
...
That is, the per-feature data available for matching depends on the type
of feature that was matched:
- "key features": only 'Name' is available
- "value features": 'Name' and 'Value' can be used
- "instance features": all attributes of the matched instance are
available
NOTE: In case of matchAny is specified, the template is executed
separately against each individual matchFeatures matcher and the
eventual set of labels is a superset of all these expansions. Consider
the following:
- name: <name>
labelsTemplate: <template>
matchAny:
- matchFeatures: <matcher#1>
- matchFeatures: <matcher#2>
matchFeatures: <matcher#3>
In the example above (assuming the overall result is a match) the
template would be executed on matcher#1 and/or matcher#2 (depending on
whether both or only one of them match), and finally on matcher#3, and
all the labels from these separate expansions would be created (i.e. the
end result would be a union of all the individual expansions).
NOTE 2: The 'labels' field has priority over 'labelsTemplate', i.e.
labels specified in the 'labels' field will override any labels
originating from the 'labelsTemplate' field.
A special case of an empty match expression set matches everything (i.e.
matches/returns all existing keys/values). This makes it simpler to
write templates that run over all values. Also, makes it possible to
later implement support for templates that run over all _keys_ of a
feature.
Some example configurations:
- name: "my-pci-template-features"
labelsTemplate: |
{{ range .pci.device }}intel-{{ .class }}-{{ .device }}=present
{{ end }}
matchFeatures:
- feature: pci.device
matchExpressions:
class: {op: InRegexp, value: ["^06"]}
vendor: ["8086"]
- name: "my-system-template-features"
labelsTemplate: |
{{ range .system.osrelease }}system-{{ .Name }}={{ .Value }}
{{ end }}
matchFeatures:
- feature: system.osRelease
matchExpressions:
ID: {op: Exists}
VERSION_ID.major: {op: Exists}
Imaginative template pipelines are possible, of course, but care must be
taken in order to produce understandable and maintainable rule sets.
2021-05-04 16:30:06 +03:00
|
|
|
# labelsTemplate: |
|
|
|
|
# {{ range .pci.device }}my-pci-device.{{ .class }}-{{ .device }}=with-cpuid
|
|
|
|
# {{ end }}
|
|
|
|
# matchFeatures:
|
|
|
|
# - feature: pci.device
|
|
|
|
# matchExpressions:
|
|
|
|
# class: {op: InRegexp, value: ["^06"]}
|
|
|
|
# vendor: ["8086"]
|
|
|
|
# - feature: cpu.cpuid
|
|
|
|
# matchExpressions:
|
|
|
|
# AVX: {op: Exists}
|
2021-06-18 18:29:08 +03:00
|
|
|
#
|
|
|
|
# # The following examples demonstrate vars field and back-referencing
|
|
|
|
# # previous labels and vars
|
|
|
|
# - name: "my dummy kernel rule"
|
|
|
|
# labels:
|
|
|
|
# "my.kernel.feature": "true"
|
|
|
|
# matchFeatures:
|
|
|
|
# - feature: kernel.version
|
|
|
|
# matchExpressions:
|
|
|
|
# major: {op: Gt, value: ["2"]}
|
|
|
|
#
|
|
|
|
# - name: "my dummy rule with no labels"
|
|
|
|
# vars:
|
|
|
|
# "my.dummy.var": "1"
|
|
|
|
# matchFeatures:
|
|
|
|
# - feature: cpu.cpuid
|
|
|
|
# matchExpressions: {}
|
|
|
|
#
|
|
|
|
# - name: "my rule using backrefs"
|
|
|
|
# labels:
|
|
|
|
# "my.backref.feature": "true"
|
|
|
|
# matchFeatures:
|
|
|
|
# - feature: rule.matched
|
|
|
|
# matchExpressions:
|
|
|
|
# my.kernel.feature: {op: IsTrue}
|
|
|
|
# my.dummy.var: {op: Gt, value: ["0"]}
|
2021-12-13 14:19:36 +02:00
|
|
|
#
|