Skip to content

Default ownerReference for NodeFeature should be Node #2039

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
ahmetb opened this issue Feb 3, 2025 · 3 comments · May be fixed by #2041
Open

Default ownerReference for NodeFeature should be Node #2039

ahmetb opened this issue Feb 3, 2025 · 3 comments · May be fixed by #2041
Assignees
@ozhuraki
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@ahmetb
Copy link
Member

ahmetb commented Feb 3, 2025

What would you like to be added:

I think the default/out-of-box behavior when NFD is installed should be that the NodeFeature CRs should have their owner reference set to v1.Node object.

Why is this needed:

The rationale is basically summarized at https://ahmet.im/blog/nfd-incident/. Basically, any other alternative is worse:

  • Owner is DaemonSet Pod (current default): Means your node labels are gonna get cleared during a rolling update of daemonset. No-go for a lot of installations that want to guarantee labels will always be there.
  • No owner (configured via a CLI flag): Means you'll leak NodeFeature CRs (though the controller can totally clean these up during periodic resyncs if it has that logic in nfd-gc).

Parenting to v1.Node has the following advantages:

  • NodeFeature resource doesn't get randomly deleted by the controller (and cause incidents like the one linked above) and its lifespan is now tied to Node itself.
  • Eliminates the need for nfd-gc as Kubernetes garbage collector in kube-controller-manager would now handle the removal.

I can't think of any downsides to having a single ownerReference set to the Node object.
@ahmetb ahmetb added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 3, 2025
@ozhuraki
Copy link
Contributor

ozhuraki commented Feb 4, 2025

/assign @ozhuraki

@ozhuraki ozhuraki linked a pull request Feb 5, 2025 that will close this issue
Open
@k8s-triage-robot
Copy link

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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label May 5, 2025
@ahmetb
Copy link
Member Author

ahmetb commented May 5, 2025

/lifecycle frozen

@k8s-ci-robot k8s-ci-robot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ozhuraki ozhuraki

Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

nfd-worker: Add support to configure the ownerReference to Node ozhuraki/node-feature-discovery
4 participants
@ahmetb @ozhuraki @k8s-ci-robot @k8s-triage-robot