node-feature-discovery
node-feature-discovery copied to clipboard
Drop support for hooks
What would you like to be added:
Deprecate and eventually remove support for hooks in the local feature source.
Why is this needed:
In #855 @eero-t had a merituos pondering why hooks should removed. Some rationale why hooks are bad and we want to disable them:
- container image maintenance and size
- feature files provide basically the same functionality with a more controllable/maintainable approach
- possible security issues
- resource consumption of buggy or bad-behaving hooks
Plan
- n (v0.12): declare hooks as deprecated, introduce config option to disable them but have them still enabled by default (#855)
- n+1: disable hooks by default but have still the option to enable them
- n+2: drop hooks support entirely, make minimal image the default image, drop the big image or e.g. rename it to -debug
n+2: drop hooks support entirely, make minimal image the default image, drop the big image or e.g. rename it to -debug
I would propose NFD to drop the big image completely, and add an initcontainer that removes host source.d/ subdirectory content, if it exists ("os.removeAll(path)"). All this should of course have prominent warnings in NFD release notes and worker log.
I.e. if one wants to continue using hooks, one would need to restart things installing hooks, in addition to downgrading back to NFD version supporting them.
n+X release would eventually drop the hook removal initcontainer.
@mythi Any comments from the Intel device plugins (which are currently using hooks) maintenance side?
I would propose that:
- #858 is implemented before this (if accepted), as it's an alternative for labels that may need to be updated during NFD run-time
- #857 is implemented at the same time as this, so that features moved from hooks to feature files need to be updated only once
@mythi Any comments from the Intel device plugins (which are currently using hooks) maintenance side?
running the source binaries in our initContainers (instead of using the initContainers to install the binaries) and piping the output to, e.g., tee /etc/kubernetes/node-feature-discovery/features.d/foo.feature should work equally well.
I have had sooooo many conversations recently, that I can't not support this issue moaaaarrr. 👍🏽 👍🏽
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
/remove-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
/remove-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
This will still take a few releases to completely drop the hooks, I think
/remove-lifecycle stale
Hooks were marked as deprecated in v0.12, we switched to the "minimal" container image as a default in v0.13 and hooks were now disabled by default in v0.14. As per our deprecation policy I think we could drop them completely already in v0.15 but I don't know if we have such a hurry (as they're now disabled anyway) so we could wait one more release for possible users to migrate off them. /milestone v0.16
v0.15 release could include note that it will be dropped in v0.16:
Upcoming API changes:
- Deprecated hook support will be dropped in v0.16 release
v0.15 release could include note that it will be dropped in v0.16:
Definitely. And if people are in (in dropping in v0.16), we could even put it in the deprecation note in the documentation that hook support is slated for complete removal in v0.16.
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
Ach, we forgot to explicitly mention the removal of hooks in the v0.15 release notes 🤦♂️ Maybe we can keep them for one release and in v0.16. They are disabled by default, anyway, so there's no major practical impact
/remove-lifecycle stale /milestone v0.17
Document the upcoming removal of hooks: https://github.com/kubernetes-sigs/node-feature-discovery/pull/1573
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
/remove-lifecycle stale