V0.15 or v0.16?

V0.15 or v0.16?

Depends on people's time, I guess 😇 We could have something small already in v0.15

/assign

Two questions here:

• regarding setting the max number of taints, labels, and ERs: If the requested number exceeds the max, should we skip the nodes' update or update the nodes with a subset of labels? e.g. if the max is 10 labels and the request has 12 labels, we only take the first 10 labels.
• In the filtering of which NodeFeature to watch, I'm currently thinking of passing a regex of <namespace>/<name>, so users can have the most flexibility (with a default of */*. Any objections here?

wdyt @marquiz @ArangoGutierrez ?

Thanks @AhmedGrati for working on this.

• About limiting the max number of labels&co: if we do this, I think it should be "transactional", all-or-nothing. So that nothing gets published if the limit is hit. But looking at my nonchalant list of wishes in the description I'm not sure how important this particular feature is 😅
• About the name(space) filtering, I'd be inclined to keep it simple, based on just namespace. Easier to understand and debug, even if not as flexible. I think the main motivation would be to only allow namespaces that you trust. We could later add e.g. labelSelector to only pick certain objects. I think the ns filtering would probably be "extra namespaces" in addition to the NFD's own ns (i.e. the stuff from nfd-worker would always be taken, disable nfd-worker if you don't want this). Treating input values as regexps can be a bit risky business (with unintended consequences) e.g. setting kube-system would match anything with that substring in it, like marquiz-kube-system-1 so the safest option would be to just have a list of fully spelled-out names.

Happy to hear others' thoughts and opinions on this.

I updated the issue discription a bit, changing bullet list to a numbered list. For me the first two (filtering NodeFeature objects and prevent labels from 3rd party NodeFeatures) would be the most important. But it would be good to hear other opinions on this, too.

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

/remove-lifecycle stale

/assign