Drop support for hooks

[marquiz]

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 (Disable hook support 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

[eero-t]

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?

[eero-t]

I would propose that:

• Add inter process communication API for external features #858 is implemented before this (if accepted), as it's an alternative for labels that may need to be updated during NFD run-time
• Life-cycle management for external features  #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]

@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.

[ArangoGutierrez]

I have had sooooo many conversations recently, that I can't not support this issue moaaaarrr.
👍🏽 👍🏽

[k8s-triage-robot]

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/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 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