This provides support for 32-bit ARM cpuid capabilities based on
the HWCAP flags, and enables the build of NFD on the 32-bit ARM
userland - notably, this also applies to ARM64 systems that are
running userspace in Aarch32 mode, which is where this problem
was first encountered.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
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>
This adds support for making selected labels extended resources.
Labels which have integer values, can be promoted to Kubernetes extended
resources by listing them to the added command line flag
`--resource-labels`. These labels won't then show in the node label
section, they will appear only as extended resources.
Signed-off-by: Ukri Niemimuukko <ukri.niemimuukko@intel.com>
SR-IOV is a PCI attribute and also non-NIC PCI devices can have it. Therefore,
it is useful to label all PCI devices with that capability.
After this commit the following labels for Intel NICs are overlapping:
feature.node.kubernetes.io/pci-0200_8086.sriov.capable=true
feature.node.kubernetes.io/network-sriov.capable=true
Signed-off-by: Mikko Ylinen <mikko.ylinen@intel.com>
Some workloads may benefit from Intel Turbo Boost technology being
disabled. This patch sets the
'feature.node.kubernetes.io/cpu-pstate.turbo' label to 'false' if we can
detect that it has been disabled. If detection fails no label is
published.
For running end-to-end tests it is required to explicitly specify in the
command line the kubeconfig to be used, e.g.:
$ make e2e-test KUBECONFIG=$HOME/.kube/config
Extend NVDIMM (non-volatile DIMM) discovery by adding detection of DAX
mode, i.e. detection of regions in DAX/AppDirect mode.
The new label is:
feature.node.kubernetes.io/memory-nv.dax: true
- Create default yamls for deploying master and worker.
- Use kube-system namespace by default.
- Configurable namespace:
make IMAGE_REGISTRY=myhost:5000 K8S_NAMESPACE=my-nfd-devel
Also, slightly adjust the deployment instructions in README to point out
that the templates should now be usable as is to run the latest released
version of NFD.
Add 'cpuid/attributeBlacklist' and 'cpuid/attributeWhitelist' config
options for the cpu feature source. These can be used to filter the set
of cpuid capabilities that get published. The intention is to reduce
clutter in the NFD label space, getting rid of "obvious" or misleading
cpuid labels. Whitelisting has higher priority, i.e. only whitelist
takes effect if both attributeWhitelist and attributeBlacklist are
specified.
Point to the latest release in the README, and, point out that a
user-built custom image is required to run the latest development
version. Update the deployment instructions to reflect the need to
specify the container image when using the deployment spec template(s).
Also, update the Job deployment script to set a user-defined container
image.
Remove 'cpuid', 'pstate' and 'rdt' feature sources and move their
functionality under the 'cpu' source. The goal is to have a more
systematic organization of feature sources and labels. After this change
we now basically have one source per type of hw, one for kernel and one
for userspace sw.
Related feature labels are changed, correspondingly, new labels being:
feature.node.k8s.io/cpu-cpuid.<cpuid flag>
feature.node.k8s.io/cpu-pstate.turbo
feature.node.k8s.io/cpu-rdt.<rdt feature>
Change the structure and naming of the make variables that control the
container image name/tag that gets created. Default values and behavior
stay the same, but, this change tries to make it easier to customize the
build from command line.
Also, document all the relevant make variables in readme.
Move the documentation of the feature detection hooks (i.e. 'local'
feature source) after all other feature sources. It is a more logical
place to document custom user-specific functionality after the built-in
features. Also, adjust the title a bit.
Detect of the Intel SST-BF (Speed Select Technology - Base Frequency)
has been enabled.
Adds one new feature label:
feature.node.kubernetes.io/cpu-power.sst_bf.enabled=true
Based on a patch from kuralamudhan.ramakrishnan@intel.com
The aim here is to add another way to specify labels using the local
source by reading files in a specific directory. That avoids us to
execute a hook when we just need to get the content of a file.
See https://github.com/kubernetes-sigs/node-feature-discovery/issues/226
Signed-off-by: Jordan Jacobelli <jjacobelli@nvidia.com>
Add two new attributes 'VERSION_ID.major' and 'VERSION_ID.minor' to the
os_release feature. These represent the first two components of
the OS version (version components are assumed to be separated by a
dot). E.g. if VERSION_ID would be 1.2.rc3 major and minor versions would
be 1 and 2, respectively:
feature.node.kubernetes.io/system-os_release.VERSION_ID=1.2.rc3
feature.node.kubernetes.io/system-os_release.VERSION_ID.major=1
feature.node.kubernetes.io/system-os_release.VERSION_ID.minor=2
The version components must be purely numerical in order for them to be
advertised. This way they can be fully (and reliably) utilized in
nodeAffinity, including relative (Gt and Lt) operators.
Remove the 'selinux' feature source and move the functionality under the
'kernel' feature source. The selinux feature label is changed to
feature.node.kubernetes.io/selinux.enabled
The selinux feature source was rather narrow in scope, and, the sole
feature it advertised naturally falls under the kernel feature source.
Currently, it only detects one feature, i.e. hardware multithreading
(such as Intel hyper-threading technology). The corresponding feature
label is:
feature.node.kubernetes.io/cpu-hardware_multithreading=true
However, this (architecture/platform dependent) feature is not detected
directly, and, the heuristics can be mislead. Detection works by
checking the thread siblings of each logical (and online) cpu in the
system. If any cpu has any thread siblings the feature label is set to
true. Thus, hardware multithreading could be effectively disabled e.g.
by putting all sibling cpus offline (even if the technology would be
enabled in hardware).
Implement new 'system' feature source. It now detects OS release
information from the os-release file, assumed to be available at
/host-etc/os-release. It currently creates two labels (assuming that the
corresponding fields are found in the os-release file), with example
values:
feature.node.kubernetes.io/system-os_release.ID=opensuse
feature.node.kubernetes.io/system-os_release.VERSION_ID=42.3
Also, update the template spec to mount /etc/os-release file from the
host inside the container.
Change links in README.md and RELEASE.md to point to the new repo
location under kubernetes-sigs. Also, remove some outdated references to
kubernetes incubator project.
This implementation only detects kconfig options ("NO_HZ", "NO_HZ_IDLE",
"NO_HZ_FULL" and "PREEMPT"). The corresponding node labels will be
node.alpha.kubernetes-incubator.io/nfd-kernel-config.<option name>
Currently, only bool and tristate (i.e. '=y' or '=m') kernel config
options are supported. Other kconfig types (e.g. string or int) are
simply ignored. If the kconfig flag is set to '=y' or '=m', the
corresponding node label will be present and it's value will be 'true'.
Make it possible for the hooks to fully define the label name to be used
(i.e. without the '<hook name>-' prefix) by prefixing the printed
feature names with a slash ('/'). This makes it possible to e.g.
override labels create by other sources.
For example having the following output from a hook:
/override_source-override_bool
/override_source-override_value=my value
will translate into the following feature labels:
feature.node.kubernetes.io/override_source-override_bool = true
feature.node.kubernetes.io/override_source-override_value = my value
Make the feature detector hooks, run by the 'local' feature source,
support non-binary label values. Hooks can advertise non-binary value by
using <name>=<value> format.
For example, /etc/kubernetes/node-feature-discovery/source.d/myhook
having the following stdout:
LABEL_1
LABEL_2=foobar
Would translate into the following labels:
feature.node.kubernetes.io/myhook-LABEL_1 = true
feature.node.kubernetes.io/myhook-LABEL_2 = foobar
Implement a new feature source named 'local' whose only purpose is to
run feature source hooks found under
/etc/kubernetes/node-feature-discovery/source.d/ It tries to execute all
files found under the directory, in alphabetical order.
This feature source provides users a mechanism to implement custom
feature sources in a pluggable way, without modifying nfd source code or
Docker images.
The hooks are supposed to print all discovered features in stdout, one
feature per line. The output in stdout is used in the node label as is.
Full node label name will have the following format:
feature.node.kubernetes.io/<hook name>-<feature name>
Stderr from the hooks is propagated to nfd log.
This commit fixes demo video broken link (from png to svg image) and updates
link to `node-feature-discovery-job.yaml.template` file.
Signed-off-by: Obed N Munoz <obed.n.munoz@intel.com>
Add a new 'kernel' feature source, detecting the kernel version. The
kernel version is split into multiple labels in order to make this more
usable in label selectors. Kernel version in the format X.Y.Z-patch will
be presented as
node.alpha.kubernetes-incubator.io/nfd-kernel-version.full=X.Y.Z-patch
node.alpha.kubernetes-incubator.io/nfd-kernel-version.major=X
node.alpha.kubernetes-incubator.io/nfd-kernel-version.minor=Y
node.alpha.kubernetes-incubator.io/nfd-kernel-version.revision=Z
The '.full' label will always be avaiable. The other labels if these
components can be parsed from the kernel version number.
Add new config option for specifying the device label, i.e. the
<device-label> part in
node.alpha.kubernetes-incubator.io/nfd-pci-<device label>.present
The option is a list of field names:
"class" PCI device class
"vendor" Vendor ID
"device" Device ID
"subsystem_vendor" Subsystem vendor ID
"subsystem_device" Subsystem device ID
E.g. the following command line flag can be used to use all of the
above:
--options='{"sources": {"pci": {"deviceLabelFields": ["class", "vendor", "device", "subsystem_vendor", "subsystem_device"] } } }'
User can now configure the list of device classes to detect, either via
a configuration file or by using the --options command line flag.
An example of a command line flag to detect all network controllers and
("main class 0x02) and VGA display controllers ("main" class 0x03 and
subclass 0x00) would be:
--options='{"sources": {"pci": {"deviceClassWhitelist": ["02", "0300"] } } }'
This feature source detects the presence of PCI devices. At the moment,
it only advertises GPUs and accelerator cards, i.e. device classes 0x03,
0x0b40 and 0x12.
The label format is:
node.alpha.kubernetes-incubator.io/nfd-pci-<device label>.present
where <device label> is composed of raw PCI IDs:
<class id>_<vendor id>
Implement new '--options' command line flag that can be used to specify
config options from command line. Options specified via this command
line flag will override those read from the config file. The same format
as in the config file must be used, that is, the flag value must be
valid YAML or JSON.
Support yaml/json based config file for nfd. This commit does not add
any actual consumers for the config file, yet.
By default, nfd tries to read
/etc/kubernetes/node-feature-discovery/node-feature-discovery.conf.
This can be changed by specifying the --config command line flag.
Introduce a new scheme where features may have logical sub-components.
Rename sriov labels from the network source according to the new
pattern:
sriov -> sriov.capable
sriov-configured -> sriov.configured
Also, document this new labeling scheme in the README.
Signed-off-by: Markus Lehtonen <markus.lehtonen@intel.com>
Convert resource templates from json to yaml
Yaml is easier and less error prone to modify by hand. It also allows
comments which can be especially useful in the templates.
Make it possible to specify an image build tool other than docker - a
limitation is that the build tool must be compatible with docker files,
of course. This makes it possible to build an NFD image without the
Docker daemon, for example.
The image build command is specified in a makefile variable and can be
overridden from command line, for example:
$ make IMAGE_BUILD_CMD="buildah bud"
Thanks: Zvonko Kosic for suggesting this
* Arrange feature sources alphabetically
Just a cosmetic change, but, a small readability improvement.
* Implement detection of IOMMU (#136)
Add a new feature source, i.e. 'iommu', which detects if an IOMMU is
present and enabled in the kernel. The new node label is
node.alpha.kubernetes-incubator.io/nfd-iommu-present
A "newbie style" deployment attempt was made on a recent
cluster, and some added notes in README and in label-nodes.sh
could help someone who just started with node-feature-discovery.
Correcting also description of label-nodes.sh which does not
deal with unlabeled nodes as was promised in README.
* Re-order imports in main.go alphabetically
* Refactor argument parsing
* Run nfd periodically in a loop by default
* Implement --sleep-interval command line option
* Add template for running nfd as a Kubernetes DaemonSet
This commit:
- enables node-feature-dicovery to advertise selinux status
on the node by adding a label.
- update the template to mount /sys into the container, this is
needed to know about the selinux status on the host
- adds selinux source for unit tests
This change adds feature source "storage".
Add label if any non-rotational block device is present in the node.
The label will be: nfd-storage-nonrotationaldisk=true
* Adding SR-IOV capability discovery to node-feature-discovery
* SR-IOV capability discovery in NFD : code update after PR review
- using hostnetwork instead of volume mount in file node-feature-discovery-job.json.template
- iterating through network interfaces that are "up" in sources.go
- inserting logs in sources.go
- change in feature source name from "netid" to "network" in sources.go, README.md and main.go
* Added code for labels sriov=true (sriov_totalvfs > 0) and sriov-configured=true (sriov_numvfs > 0)
* Code Refactored: Added Network package and network.go
