The test was broken twofold: Firstly, the annotation was not checked at
all because the name of the node where nfd-master is running was not
set. Secondly, the annotation prefix was used incorrectly.
We need the latest version to support client.authentication.k8s.io/v1.
The previous version we used only supported v1alpha1 which was dropped
in K8s v1.24.
Update the partial list of x86 cpuid features that are presented in the
NFD documentation. In particular, the following instructions were left
out of the list: AVXSLOW, CETIBT, CETSS, CLDEMOTE, HLE, MPX, RTM,
RTM_ALWAYS_ABORT, SERIALIZE, SHA, TSXLDTRK.
Ignore the operational state of network interface when creating the
network SR-IOV labels. Previously NFD only considered interfaces which
were "up".
Pre v0.9 we used to check the "administrative state" of interfaces
(managed by the sysadmin with e.g. with ip link set dev <dev> down/up).
In v0.10 we changed to checking the "operational state" of interfaces,
reflecting whether the it is actually able to transfer data. Both these
checks have caused confusion among users and it is more understandable
and more aligned with other HW discovery functions in NFD to just drop
the state check. Also, the documentation is aligned with this behavior.
Let the documentation follow the latest release name. Even if it's just
referential here it would look odd in the future if we refer to some
ancient version.
Set `cpu.se-enabled` to `true` when IBM Secure Execution for Linux
(IBM Z & LinuxONE) is available and has been enabled.
Uses `/sys/firmware/uv/prot_virt_host`, which is available in kernels
>=5.12 + backports. For simplicity, skip more complicated facility &
kernel cmdline lookups.
This patch changes a rare corner case of custom label rules with an
empty set of matchexpressions. The patch removes a special case where an
empty match expression set matched everything and returned all feature
elements for templates to consume. With this patch the match expression
set logically evaluates all expressions in the set and returns all
matches - if there are no expressions there are no matches and no
matched features are returned. However, the overall match result
(determining if "non-template" labels will be created) in this special
case will be "true" as before as none of the zero match expressions
failed.
The former behavior was somewhat illogical and counterintuitive: having
1 to N expressions matched and returned 1 to N features (at most), but,
having 0 expressions always matched everything and returned all
features. This was some leftover proof-of-concept functionality (for
some possible future extensions) that should have been removed before
merging.
