additional dmi attributes / annotations

[ctrought]

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]

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]

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]

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