Take the default value displayed for the image.repository Helm chart
parameter dynamically from the Jekyll configuration. This way, we
get the correct value for releases/release branches.
Build a "minimal" variant of the nfd image based on
gcr.io/distroless/base. The motivations behind the minimal image are
image hardening (security) and reducing the image footprint (from ca.
108MB down to about 40MB).
The practical effect of deploying the minimal image is that no runtimes
for running worker hooks are present, not even a shell. This means that
only statically linked linked hook binaries are supported. Also, because
of the image hardening live debugging of the minimal image by attaching
to the container is not possible, and, the "full" image needs to be used
for that purpose.
Make the update-gh-pages.sh script to maintain a Helm charts repository
under charts/ subdirectory in gh-pages. The script now (always) scans
throught all release assets and injects any found Helm chart archives
into the Helm repo. In practice, new assets in all Github releases are
scanned and the Helm repo is updated on any update of the master or
release branches or on any new tags. Asset ids are tracked/cached in
order to avoid unnecessary downloads, but also, to capture any changes
in assets that were already merged in the repo index.
After this a user is able to do something like
$ helm repo add nfd http://kubernetes-sigs.github.io/node-feature-discovery/charts
...
$ helm repo update
...
$ helm install nfd/node-feature-discovery --namespace nfd --create-namespace --generate-name
...
This adds additional cpu features:
- pstate status from status of intel_pstate driver
- pstate scaling settings from scaling_governor
- cstate enable from max_cstates in intel_idle driver
The code should be stable enough. If there are fatal bugs causing the
discovery to panic/segfault that should be made visible instead of
semi-siently hiding it. Also, this caused one (negative) test case to
fail undetected which is now fixed.
After moving to the flags package for command line argument parsing NFD
accepts command line arguments (flags) starting with a single dash (e.g.
-no-publish in addition to --no-publish). Even if double-dash can be
used the single-dash version is printed e.g. in the usage string (from
-h, -help) so align documentation with that.
There are cases when the only available metadata for discovering
features is the node's name. The "nodename" rule extends the custom
source and matches when the node's name matches one of the given
nodename regexp patterns.
It is also possible now to set an optional "value" on custom rules,
which overrides the default "true" label value in case the rule matches.
In order to allow more dynamic configurations without having to modify
the complete worker configuration, custom rules are additionally read
from a "custom.d" directory now. Typically that directory will be filled
by mounting one or more ConfigMaps.
Signed-off-by: Marc Sluiter <msluiter@redhat.com>
