Consider moving to cpu flags about node-feature-discovery HOT 10 CLOSED

Obviously this would make NFD job easier, but there likely was reason why this was not the method from very start. It's a fundamental question should NFD consider features which are either
a) "supported in HW and detected by kernel"
or b) "supported in HW"
and b) was selected, leaving kernel out of path.
One reason coming to mind is, by relying on kernel-detected flag, NFD may miss some newer
features which are not listed by older kernel. I recall someone said that lot of k8s servers run
CentOS-7 which runs kernel 3.10. And is it possible some application can use CPU feature (like instruction set extension?) even if kernel is older and has not detected it? That's one scenario that might be behind thinking why b) was selected.
Has such a design selection been documented somewhere? I looked into design doc pointed from README but did not find it.

from node-feature-discovery.

from node-feature-discovery.

If this is desired, the existing cpuid
source plugin could stay
and this issue can be renamed to 'add cpuflags source plugin'.

Yep, I wouldn't remove the existing functionality, i.e. CPUID plugin. Write a new plugin, if needed.

But, I'm not necessarily very enthusiastic about this. My concern is the flat structure of labels, which would be cluttered with mostly uninteresting flags (that's prolly true with the existing CPUID flags, already). There are easily over 100 cpu kernel flags. I don't know if this really is a problem, though.

from node-feature-discovery.

I filed the issue to open the discussion. The problem I see is cpuid plugin can give false result for what is really supported (see #130).

from node-feature-discovery.

I would not say "cpuid plugin gives false result".
It gives us correct facts in CPU capability domain, just that in SGX case we additionally need other facts from other domains to get full SGX capability. The name of flag fortunately is cpuid-SGX which reflects the scope quite well.

from node-feature-discovery.

@okartau true, s/false/incomplete/

from node-feature-discovery.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

from node-feature-discovery.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

from node-feature-discovery.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

from node-feature-discovery.

@fejta-bot: Closing this issue.

from node-feature-discovery.