feat: add ability to export feature labels for static node

[vsoch]

Problem: We want to use NFD (labels and other functionality) for HPC, but a Kubernetes environment is expected.
Solution: Add an nfd-worker --export mode that allows for generation and export of static labels.

For the HPC use case, we want to be able to export static features without Kubernetes, either to the screen (for inspection) or a file (for saving and use with a scheduler, or other compatibility checking algorithm). Adding support for this is fairly easy - we need to just expose the flag, disable the check for Kubernetes assets, and then generate the labels once and exit (without starting or sending to a server). The usage is simple and intuitive:

# Export labels to the terminal for inspection
nfd-worker --export

# Save to a file path
nfd-worker --export=labels.json

The flag is also useful for cases beyond HPC when a quick inspection is desired. Note that instead of adding two flags (a boolean for export, and string for a filepath) I opted for the design above - one flag that supports being used as a boolean or providing a path. A new flag type is added to support that, and it is generic so could be used for other future cases. For my implementation, for us to check how this new flag was set, we need to pass it to the initFlags function:

args, overrides := initFlags(flags, &exportFlag)

And I think this is OK for now, but if more flags were defined in this manner, we would want to pass a structure with all of them. I decided that was overkill for the time being. For another design choice, I think the generation of the labels should be in the same function to Run(), and to support this I check w.args.Export before setting up any servers / Prometheus, and run the generation (that will handle the export to terminal or file and exit early, if applicable). I have also added tests and documentation, and I tested on an HPC node (in user space) to make sure the labels generated without issue.

I realize I didn't open an issue for discussion - so am happy to have it here! To better explain the use case, this is a feature intended to better support compatibility checking, but for HPC. We won't be able to run compatibility checks assuming labels are available via Kubernetes, but we will be able to export them to files that represent nodes, and then be able to use associated tools to check compatibility artifacts against the known features. This is what I'm working on today. Thanks!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: vsoch
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

[k8s-ci-robot]

Welcome @vsoch!

It looks like this is your first PR to kubernetes-sigs/node-feature-discovery 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/node-feature-discovery has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @vsoch. 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.

[netlify]

✅ Deploy Preview for kubernetes-sigs-nfd ready!

Name	Link
🔨 Latest commit	64520e3
🔍 Latest deploy log	https://app.netlify.com/projects/kubernetes-sigs-nfd/deploys/684451f1aeca62000854267d
😎 Deploy Preview	https://deploy-preview-2170--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.

[ChaoyiHuang]

# Export labels to the terminal for inspection
nfd-worker --export

# Save to a file path
nfd-worker --export=labels.json

how about using stdout to unify the commandline, for example

# Export labels to the terminal for inspection
nfd-worker --export=stdout

# Save to a file path
nfd-worker --export=labels.json

[vsoch]

@ChaoyiHuang thank you for taking a look! How would you distinguish these two?

# Export labels to the terminal for inspection
nfd-worker --export=stdout
nfd-worker --export

They are both going to dump to the output stream. Did you have in mind using different streams, or minimizing other output for the rest of the run for one case? Or are you saying to keep the command the same, but have stdout? I think the issue with that would be not knowing if a user wants to write to a file called stdout vs standard output. With just --export it is clear because the variable isn't defined.

[ChaoyiHuang]

th just --export it is clear because the variable isn't defined.

keep the command the same format (stdout is standard output).

--export is also OK, just have to code a little more.

[ChaoyiHuang]

it may just export to standard output, and no need to support export to path.

if want to save the content to file, it can be done via redirecting the output to file, for example:

nfd-worker --export > labels.json

so the code can be simplified to just support exporting to standard output

nfd-worker --export

[vsoch]

The nfd worker generates a lot of logs (and other unexpected output) so I wasn't sure how to cleanly do that. Whereas with writing the file explicitly, I can control exactly the contents.

[mfranczy]

I believe it's better to keep the worker k8s centric (as it implements the logic for updating k8s resources), operate on raw features rather than labels, and add a new subcommand to the nfd client for dumping features.

Raw features can easily be transformed into labels if needed. However, since labels are derived from raw features and the worker configuration, relying solely on labels may cause certain node capabilities to be missed due to default or custom configurations.

The same principle applies to the image compatibility implementation in NFD, where comparisons are performed by checking the features (not the labels).

Thoughts?