search

kubernetes-sigs / node-feature-discovery

Node feature discovery for Kubernetes
Apache License 2.0
726 stars 228 forks source link

additional dmi attributes / annotations #1629

Open ctrought opened 3 months ago

ctrought commented 3 months ago

What would you like to be added: We would like access to some of the dmi attributes under /sys/devices/virtual/dmi/id/

Recently sys_vendor was added via #1574 covering #1057, but would be helpful for us to have some others such as product_name to further differentiate hardware vendor by model.

I would also love having some of the other metadata available on nodes, such as bios version and serial number. These aren't so important for workload scheduling, and maybe doesn't exactly fit the exact original goal of NFD but if NFD could write the same type of node attributes to annotations on the nodes that would be helpful for us - plus it would allow for storing data in more complex format if required (e.g. ilo url, json, etc) that labels don't accept. The user could choose the target for the item (default label, or annotation) and keep track of important metadata directly on the node in k8s. The alternative is I create a custom local source, and these get added as labels which are indexed in etcd but sort of unnecessary and limits format. 

# ls -lth /sys/devices/virtual/dmi/id/
total 0
drwxr-xr-x. 2 root root    0 Feb 16 13:47 power
-r--r--r--. 1 root root 4.0K Feb 16 13:47 bios_date
-r--r--r--. 1 root root 4.0K Feb 16 13:47 bios_version
-r--r--r--. 1 root root 4.0K Feb 16 13:47 board_asset_tag
-r--r--r--. 1 root root 4.0K Feb 16 13:47 board_name
-r--------. 1 root root 4.0K Feb 16 13:47 board_serial
-r--r--r--. 1 root root 4.0K Feb 16 13:47 board_version
-r--r--r--. 1 root root 4.0K Feb 16 13:47 chassis_asset_tag
-r--------. 1 root root 4.0K Feb 16 13:47 chassis_serial
-r--r--r--. 1 root root 4.0K Feb 16 13:47 chassis_vendor
-r--r--r--. 1 root root 4.0K Feb 16 13:47 chassis_version
-r--r--r--. 1 root root 4.0K Feb 16 13:47 product_family
-r--------. 1 root root 4.0K Feb 16 13:47 product_serial
-r--r--r--. 1 root root 4.0K Feb 16 13:47 product_sku
-r--------. 1 root root 4.0K Feb 16 13:47 product_uuid
-r--r--r--. 1 root root 4.0K Feb 16 13:47 product_version
-r--r--r--. 1 root root 4.0K Feb 16 13:33 chassis_type
-r--r--r--. 1 root root 4.0K Feb 16 13:33 modalias
lrwxrwxrwx. 1 root root    0 Feb 16 13:33 subsystem -> ../../../../class/dmi
-rw-r--r--. 1 root root 4.0K Feb 16 13:33 uevent
-r--r--r--. 1 root root 4.0K Feb 16 13:33 bios_vendor
-r--r--r--. 1 root root 4.0K Feb 16 13:33 board_vendor
-r--r--r--. 1 root root 4.0K Feb 16 13:33 product_name
-r--r--r--. 1 root root 4.0K Feb 16 13:33 sys_vendor

Why is this needed: sys_vendor is available, but it is too vague if one has a mix of different models from the same vendor.

marquiz commented 3 months ago

Thanks @ctrought for reaching out. We can add other dmi attributes, too. Serial numbers is something we can't (or don't want to) add as they're only readable by root. What do you think would be valuable to add? All of them (sans serials and uevent) or some subset? Templating could be used to add these as node annotation via a NodeFeatureRule.

ctrought commented 3 months ago

they're only readable by root

ah great point, didn't notice that 👍

What do you think would be valuable to add?

product_name for sure as it will contain the HW model. Perhaps others could be useful for some users, but if they are optional would there any drawbacks to not support all accessible dmi attributes out of box? I'd probably be happy with just product_name but someone else down the road may find a need for one of the others.

k8s-triage-robot commented 3 weeks ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

TessaIO commented 1 week ago

/remove-lifecycle stale