Add option to create "profiles" of feature labels.

[nolancon]

What would you like to be added:
The ability to aggregate a number of individual feature labels into a single profile. This profile can itself be represented as a feature label.

For example, a profile should contain a list of individual features across any/all sources (cpu, pci, kernel etc). Any node on which all of these features are detected should be given an additional label (representing the name of the profile).

Expanding on this, some features in the profile may not require an exact match, but instead are satisfied by another variation(s) of the feature.

Existing feature discovery and existing feature labels are unchanged by this enhancement.

One possible implementation is to extend the existing config to include a "profile" source. Here the user defines their profile name and the list of features the profile comprises.
After feature discovery is complete across all sources, the profile is compared against the list of features already discovered. Should the discovered features match those of the profile, an additional "profile" label is added to the label list before it is returned to nfd-master for node labelling.
Implementation can be seen here: nolancon@4b04d27

Why is this needed:
This feature would reduce the laundry list of individual features listed in a pod spec for scheduling purposes. Instead of specifying each feature, application developers can add a single profile label.

[marquiz]

This is well in line with the recent development. IMHO we really should expand the capabilities of the custom source as it already has has a lot of the required infrastructure in place. I also think that we really should not look at existing labels but introduce more domain-specific matcher rules. Users must be able to disable all other sources and still get the same custom labels. Things really start to look like disabling most all the other sources (except for custom and local by default starts to be a valid option at some point in the future 🤔

With that in mind there is some code refactoring/restructuring to be done, something that I've been planning to do a long time. Steps forward:

1. Separate feature detection from label generation – run detection only once and re-use the data in multiple sources
2. Create new matchers in custom source
3. Need to think through what would be the best way to wire the local source (source.d/ and features.d/) into the custom source. I think we need the ability to wire the results of external "detectors" into the matcher engine of the custom source.

[marquiz]

I did some prototyping. #464 should basically provide the infrastructure for this. Still in early phase but seems to be working

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[marquiz]

/remove-lifecycle stale

[marquiz]

#548 allows the usage of profile.node.kubernetes.io label namespace (by default, without any extra configuration)

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[ArangoGutierrez]

/remove-lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[marquiz]

Closing this as implemented as we now have the new expression based labeling rules (deployed via NodeFeatureRule objects or nfd-worker config) plus we support profile.node.kubernetes.io/ label namespace (plus its subnamespaces).
/close

[k8s-ci-robot]

@marquiz: Closing this issue.

In response to this:

Closing this as implemented as we now have the new expression based labeling rules (deployed via NodeFeatureRule objects or nfd-worker config) plus we support profile.node.kubernetes.io/ label namespace (plus its subnamespaces).
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.