Move all content from README.md to the Jekyll site under docs/. Also
re-organize it into multiple sub-pages.
Populate README with fresh content turning it into virtually a big link
to the html-based documentation site. Spiced up with super-quick-start
instructions.
An attempt to organize the Makefile variables a bit further. The idea is
to only document variables that are really intended for build
customization and initialize all these variables in the Makefile with
'=?' so that they can be specified in the environment (and not just with
variable overrides). Thus, this patch drops some variables from the
README and change the initialization of some variables in the Makefile
so that the two files would be in sync.
make image and make push fails when trying to use an ENV VAR value, as
it is now they can only be overrided.
the Var modified are
GO_CMD
GO_FMT
IMAGE_BUILD_EXTRA_OPTS
IMAGE_BUILD_CMD
IMAGE_PUSH_CMD
IMAGE_TAG_NAME
IMAGE_REGISTRY
IMAGE_NAME
IMAGE_EXTRA_TAG_NAMES
K8S_NAMESPACE
HOSTMOUNT_PREFIX
This new behaviour has also been updated on the README.
Signed-off-by: Carlos Eduardo Arango Gutierrez <carangog@redhat.com>
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