Plugin mechanism for customer-specific labels

[marquiz]

What: provide a way for customers to write their own feature detectors, creating custom labels.

Originally, I thought, it would be sufficient to implement custom feature sources as user-specific modules under source/ directory in nfd source code. The reasoning behind this idea was that the source modules and their API to "nfd core" are simple, so writing and maintaining a custom plugin would not be too cumbersome. However, this would effectively be forking nfd, requiring maintenance of your own code base and also building and using custom Docker images.

So, I was thinking about providing some relatively simple mechanism to have custom feature detectors, without the need to fork the code or use custom Docker images.

The first, obvious, idea would be to use hooks. E.g. look under /etc/kubernetes/node-feature-discovery/source.d/ and run all executable binaries from there. The hooks would return the detected features to stdout and have logging to stderr.

E.g.
running /etc/kubernetes/node-feature-discovery/source.d/my-source would have stdout output:

FEATURE_1
FEATURE_2

which, in turn, would cause nfd to create labels

node.alpha.kubernetes-incubator.io/nfd-my-source-FEATURE_1=true
node.alpha.kubernetes-incubator.io/nfd-my-source-FEATURE_2=true

This could be easily extended to non-binary labels, too

[lmdaly]

+1 on a pluggable mechanism for specific features that are not acceptable for upstream NFD.

[marquiz]

An initial version implemented in PR #148

[MarSik]

The proposed label name seems very limiting. The custom hooks might be used to detect functionality that has been provided using manual labels so far or that integrates with other existing tools and the proposed format would not allow the use of expected label names.

I would rather let the hook scripts return the full label names to make the label independent on the project/script reporting it completely. That way the hooks can even replace a detection method that might not be appropriate for some environments or hosts and still provide the same feature labels.

[marquiz]

NFD is supposed to advertise node features, thus, I would restrict the hook to nfd labels, and not give control over the label namespace. This also relates to re-labeling which has been discussed in #176. I think it's an important feature of NFD that it is able to remove out-of-date/incorrect labels. NFD wouldn't be able to remove any old labels if the hooks had full control over the label name.

Replacing or extending existing feature sources is probably a valid use case, though. So, dropping the feature source part, i.e. local, from the label name in the current implementation makes sense.

[MarSik]

I agree, lets limit that to the feature.node.kubernetes.io/ namespace and drop the local prefix. That is completely sufficient for our use cases and sounds right to me. Thanks for listening to our wishes :)

[marquiz]

I'll rebase this changes after the repo migration has been completed, and, the label namespace change has been merged.

[MarSik]

That is awesome news, thank you.

[marquiz]

Updated version submitted. See PR #148 for details

[marquiz]

#148 merged into master