nfd-worker: Add FeatureAllowList, FeatureDenyList

[ozhuraki]

Closes: #2026

[netlify]

✅ Deploy Preview for kubernetes-sigs-nfd ready!

Name	Link
🔨 Latest commit	e41822c
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-nfd/deploys/68c04089a5ac300009191301
😎 Deploy Preview	https://deploy-preview-2255--kubernetes-sigs-nfd.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[k8s-ci-robot]

Hi @ozhuraki. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ozhuraki
Once this PR has been reviewed and has the lgtm label, please assign marquiz for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[marquiz]

Thanks @ozhuraki for starting to work on this.

I have two main comments:

1. The main motivation for this feature is decreasing the size of the NodeFeature object(s). We need filtering for the "raw" features that get into those CRs. For the labels we have adequate controls (I think).
2. We need some more expressive mechanism than one-regexp-to-rule-them-all. Like Only show cpu.cpuid.AVX512* and cpu.cpuid.AMX but nothing else or Filter out all PCI devices with class 08

[Copilot]

Pull Request Overview

This PR adds feature allowlist and denylist functionality to the nfd-worker component, providing granular control over which features are published to the Kubernetes API server. This addresses issue #2026 by implementing regex-based filtering for feature names.

• Adds FeatureAllowList and FeatureDenyList configuration options to the core config
• Implements filtering logic to check features against both allowlist and denylist patterns
• Adds command-line flags for configuring the new filter options

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
pkg/nfd-worker/nfd-worker.go	Adds core filtering functionality with config fields and filter logic
cmd/nfd-master/main.go	Adds command-line flag support for the new filtering options

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

Typo in field name: 'FeatureAlowList' should be 'FeatureAllowList' (missing 'l').

Suggested change

	FeatureAlowList: &utils.RegexpVal{},
	FeatureAllowList: &utils.RegexpVal{},

[Copilot]

The logic condition !(!denied && allowed) is unnecessarily complex and hard to read. It should be simplified to denied || !allowed using De Morgan's law for better clarity.

Suggested change

	if !(!denied && allowed) {
	if denied || !allowed {

[Copilot]

Logging when a feature doesn't match the allowlist will generate excessive log entries for every filtered feature. Consider only logging at debug level or when verbose logging is enabled to avoid log spam.

Suggested change

	klog.InfoS("feature does not match the allowlist", "feature", name, "regexp", featureAllowList.String())
	klog.V(1).InfoS("feature does not match the allowlist", "feature", name, "regexp", featureAllowList.String())

[marquiz]

We need something more structured than plain regexp. I'd suggest to drop the command line flags and make this a config-file only option.

[marquiz]

We need something more structured. One idea could be to follow something we have in NodeFeatureRules. We have stuff organized in hierarchy like <source>.<feature>.<element>. So following the NodeFeatureRule model we could have

featureDenyList:
  - feature: "kernel.config"

and then more refined configuration

featureDenyList:
  - feature: "pci.device"
    class: {op: In, value: ["0880"]}