Get rid of the dependency on intel-cmt-cat library and rdt helper
binaries written in C. Significantly simplifies the build procedure.
Implements minimal support (in assembler) for getting the raw data from
the CPUID instruction. Also, implement a stub so that the code works on
other architectures than amd64, too.
Discover other than bool or tristate kconfig options, too. For bool and
tristate the node label is still binary (i.e. set to "true" if the
kconfig option has been enabled). For other kconfig types (e.g. string
or int) the value of the label directly corresponds to the value of the
kconfig flag, e.g. "32", "elf64-x86-64" etc.
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.
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.
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>
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>
* 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
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
* Make rdt-discovery buildable outside hardcoded path
Do not assume that nfd sources always reside under hardcoded directory
"/go/src/github.com/kubernetes-incubator/node-feature-discovery/". This
makes it possible e.g. to build nfd locally outside the Docker
container.
* Do not hardcode the path for RDT helper binaries
Utilize the standard PATH env variable, instead.
* Format main,fake,network go source to improve GoReportCard
Order of import changed in main.go and network.go,
missing ending newline added in fake.go
* Fixed simple golint suggestions in multiple files
Mostly about missing or incomplete comments
* 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
