[SEL3-41] Documenting ironic known issue for network device naming #762
Conversation
|
@hardys @e-minguez could you please advise on wording, anything missing, backporting etc? I am sure this is not optimal as it was done a bit in a hurry and I am not the best with words, but it's much easier to amend this to something better than not having anything in place. Thanks! |
There was a problem hiding this comment.
I think using the UUIDs is a bit fragile. I'm not 100% sure how nmc generates those and if it changes between versions. The most robust approach is to use the proper device names. /cc @atanasdinov to double check if relying on the uuid generation is safe or not.
asciidoc/components/metal3.adoc
Outdated
| @@ -33,3 +33,5 @@ automated inspection, cleaning and provisioning/deprovisioning. | |||
| * The upstream https://github.com/metal3-io/ip-address-manager[IP Address Management controller] is currently not supported, because it is not yet compatible with our choice of network configuration tooling. | |||
| * Relatedly, the IPAM resources and Metal3DataTemplate networkData fields are not supported. | |||
| * Only deployment via redfish-virtualmedia is currently supported. | |||
| * It is possible to observe a network device name missalignment between the ironic python agent (IPA) and the target operating system (SLE Micro 6.0/6.1), especially when trying to configure predictable names for the devices. | |||
There was a problem hiding this comment.
| * It is possible to observe a network device name missalignment between the ironic python agent (IPA) and the target operating system (SLE Micro 6.0/6.1), especially when trying to configure predictable names for the devices. | |
| * It is possible to observe a network device name misalignment between the ironic python agent (IPA) and the target operating system (SL Micro 6.0/6.1), especially when trying to configure predictable names for the devices. |
There was a problem hiding this comment.
Thanks for the feedback. Using device names is also not straightforward as those are not known in advance so the customers would still need to fail, record device names and try again. Also it's not allowing automation since each server might have different device naming
There was a problem hiding this comment.
I agree it is not ideal but I feel it is more robust than relying on the uuid being generated by nmc. I guess we should perhaps document both options?
/cc @hardys for his inputs.
…etwork configuration
|
Just in case, it seems it is not that fragile but based on the interface name and interface type https://github.com/nmstate/nmstate/blob/e05e1f25fd72808d55b837346b489b4669eb823c/rust/src/lib/nm/settings/connection.rs#L430-L440 |
https://jira.suse.com/projects/SEL3/issues/SEL3-41?filter=allopenissues