Label Templates: Hardware variables rework

[fgiudici]

The Hardware data collected during the host registration is altered before being sent to the Elemental Operator, in order to make it easier to consume.

Anyway, this wrapping process should be improved fixing the format of the data (e.g., ${CPU/Capabilities} is filled as a slice of strings, that fails to be rendered) and allowing to enumerate block and network devices without knowing their device name (which brings to some nonsense variables like ${System Data/Network/{Iface name}/Name}, where the rendered value is equal to what you have to put in the template as the {Iface name}).

This issue tracks:

• fix the format of all the exported variables (output should always be a string)
• add block and network device data retrieval without knowing their name

sibling doc issue: rancher/elemental-docs#374

[gervaso]

Hello, following this!
I would also suggest to make network interfaces mac addresses available as variables if possible.
Some existing existing use cases rely on the "primary" interface mac address to identify a device, basically basing the hostname on that.
We're currently testing elemental as a means to manage remote IoT devices which will run k3s, but so far we are having a hard time identifiying them once they register because unfortunately the OEM is not setting UUID, serial or SKU data in smbios and so all the hardware looks the same to the elemental operator.

[fgiudici]

Hey @gervaso 👋🏼
actually the MAC is already available also if not documented: you will anyway need to know the interface name to get it.
It would be:
${System Data/Network/{Iface name}/MacAddress}
where "{Iface name}" is the actual named interface. To be explicit, if the NIC on your system is 'eth0', the MAC would be available at:
${System Data/Network/eth0/MacAddress}

[gervaso]

Oh, this is a very useful piece of information I've been missing out. I'll put it to good use in a flash!
Thank you.