node-feature-discovery
node-feature-discovery copied to clipboard
kubernetes-sigs
Use shorter label namespace
What would you like to be added:
I'd like to move to a shorter label namespace (e.g. nfd.k8s.io/ or feature.node.k8s.io/) before nfd v1.0. I'm not sure what would be the least painful way there (or if it even is worth it).
One path could be:
- Allow the shorter namespace. For custom labels only
- Have an option to switch to the shorter namespace for all labels (the old long namespaces would still be the default)
- Make the new namespace the default for built-in labels. Have an option to use the old one instead
- Drop the compatibility mode (no hurry with this)
Why is this needed:
Usability
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
@zvonkok @ArangoGutierrez what do you think about this? Is it too disruptive?
OTOH we can start implementing this with the two first steps (allow nfd.k8s.io and create a flag for turning that on for all labels). This gives us time to experiment and get feedback based on which we can do the switchover of back off.
Agree that this should be optional for some time. Many workloads might have hard coded the current schema.
Question: can we use k8s when becoming a 1.0 API?
I think labels this is ok already now. The long current one (feature.node.kubernetes.io) was agreed in SIG node years ago.
I think it is better if we keep discussion notes here. So, I will copy paste my comments here from the https://github.com/kubernetes-sigs/node-feature-discovery/pull/881.
This is a breaking change, and usually in k8s for such a change it takes ~3-4 releases to remove a feature. Example: rename "node-role.kubernetes.io/master" node-role.kubernetes.io/master label & taint renaming in Kubeadm, they had both labels in parallel that gave time to users to switch to the new format. And perhaps we can follow the same path?
For example,
Release - v0.12.X
- introduce a short label and a flag to switch between long and short labels
- set the flag to use long label by default
- announce to community/users to adapt to use the short label
- get community/users feedback
Release - v0.13.X
- turn on both short and long labels by default but still have an option to disable them
- get community/users feedback
Release - v0.14.X
- Turn off long label by default but still have an option to enable it
Release - v0.15.X
- Remove the long label entirely from the codebase and keep only short label
- Remove the flag to switch between short and long labels
I'm not sure about the estimated time between MINOR releases in NFD project, but if you think it is too short that we take above steps in every MINOR release, then of course we can extend it. And actually better if we get users feedback on that.
Patch for the first step is ready for review in https://github.com/kubernetes-sigs/node-feature-discovery/pull/881 and if you folks agree with the plan then let's move on. Any comments, thoughts, concerns are welcome. I will also spread the word on the slack.
What if for a next step we make it optional?
in the CRD add an entry short namespace :yes/no
thoughts?
What if for a next step we make it optional? in the CRD add an entry
short namespace :yes/nothoughts?
As per discussion on the slack, I was thinking of introducing a flag to turn on/off the new label but I'm also fine with the CRD as well. TBH, I don't have a strong opinion which was one is better.
What CRD are you referring to? If it's operator then sure. But this needs to be a single config option in nfd-master (i.e. cluster-wide)
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
I think we're not doing this for now. Too much hassle, especially for the end user. Ref discussion in #881 /close
@marquiz: Closing this issue.
In response to this:
I think we're not doing this for now. Too much hassle, especially for the end user. Ref discussion in #881 /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.
