Improve naming convention for Machine, NIC, Network objects and related objects

[hardikdr]

Summary

The naming convention of the Machine, NIC, Network objects and other related objects needs to be improved to make them more SRE-friendly and debug-friendly.

Currently, the names are not very convenient for debugging purposes, especially when multiple region/AZ clusters are layered. While there are security concerns with copying end-user-provided names to the VM cluster, the current solution of copying the machine-uid as a label is also not very convenient.

Proposed solution

One possible solution is to introduce an instance-id similar to AWS, and copy this across objects at all layers. This would provide a more convenient and secure way to name these objects.

Motivation

Ease of debugging, Security, and Consistency with industry standards.

[hardikdr]

cc @gehoern @adracus

[adracus]

@hardikdr with "Naming Conventions", what are you referring to? A user of the onmetal-api can specify names as he or she wishes. Could you please elaborate more what you're seeing from which component in the onmetal-api that requires changes?

[hardikdr]

I point to the naming of the objects that are passed to the pool-clusters. A simple example, of Machines specifically:

Region/End-user-facing cluster

my-machine  x3-xlarge         <none>   pool1   Running   30m

This is converted to the following in the AZ cluster:

AZ1 cluster:

mypoollet-system   12019901783616d84f7f1a806e948abc90a017c54eb3ac2450a0835a0322a23   x3-xlarge         <none>   pool2         Running   30d

Which is then converted into a VM cluster:
VM/Provider-Cluster:

mypoollet-system   007378663960366423c707e044819ee08b6e392ff8d7b5dc1e87e8eaf32d765   x3-xlarge         <none>                                             pool3   Running   30m

In order to determine 007378663960366423c707e044819ee08b6e392ff8d7b5dc1e87e8eaf32d765 from the my-machine, labels of Machines in all the layered clusters need to be tranversed. There could be possibly even more layers in between with more AZ clusters.
It could be easier to have one instance-id, that's labeled or even used as a name in all the subsequent clusters.