Discover TDP of the CPU about node-feature-discovery HOT 6 CLOSED

@lmdaly: could you elaborate on the details and use case of this. Based on the discussion in SIG-node meeting yesterday, I feel that I've not completely/correctly understood the request.

I have a prototype implementation. However, that detects the "thermal specification power" (i.e. "nominal TDP") from msr 0x614, which is fixed value and determined by the (cpu) package specification. This is probably not what you want. Are "package power limit" settings the information you'd like to have, or something else?

from node-feature-discovery.

What is the use case for this?
Power limits can be configured by anyone with root access to the host. I don't think we should publish numbers as values for labels. It will be a UX issue to use label selectors as they don't support relational operations.

from node-feature-discovery.

Yeah, I think I agree with @balajismaniam here. I'm probably not that concerned about the tampering of power limits (as NFD will update the labels, if run as a DaemonSet), but, merely about the usefulness of the (numerical) label. In general, it might cause more harm than good because of the limitations of label selectors.

If this information really is needed, the solution could be user-specific custom feature source(?)

from node-feature-discovery.

I agree here that this feature may not be suitable for upstream K8s due to it's variable nature based on different processes. +1 for custom feature source/pluggable label

from node-feature-discovery.

It will be a UX issue to use label selectors as they don't support relational operations.

I just realized that relational operations (Lt and Gt) actually ARE supported, when using nodeAffinity (instead of nodeSelector)

from node-feature-discovery.

Closing this as "not to be implemented"

from node-feature-discovery.