Skip to content
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.

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

Default ownerReference for NodeFeature should be Node #2039

Open
ahmetb opened this issue Feb 3, 2025 · 1 comment · May be fixed by #2041
Open

Default ownerReference for NodeFeature should be Node #2039

ahmetb opened this issue Feb 3, 2025 · 1 comment · May be fixed by #2041
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants