To add some color on the background for our wish to use FQDNs it goes beyond fixing Masakari, we are also increasingly met with other subsystems with FQDN as a default like OVS/OVN, so continuing with just the shortname will be a uphill battle. We have also faced brittleness in meeting other subsystems configuration issues, like missing search domain configuration.
I do see your concerns about using something bound to a interface name or other mutable/likely to change over a clouds lifetime values.
The concerns Chris raises in #10 are also 100% valid and valuable, and I think we can address that concern with the existing migration network binding/configs.
To amend my comment in #8 there actually is a libc call we can use to get the "official" name of a host (this is also what `hostname -f` uses), with rigorous fallback that might do it.
In any case we must ensure that the principle and subordinate charm on a single host agree on their name.
To add some color on the background for our wish to use FQDNs it goes beyond fixing Masakari, we are also increasingly met with other subsystems with FQDN as a default like OVS/OVN, so continuing with just the shortname will be a uphill battle. We have also faced brittleness in meeting other subsystems configuration issues, like missing search domain configuration.
I do see your concerns about using something bound to a interface name or other mutable/likely to change over a clouds lifetime values.
The concerns Chris raises in #10 are also 100% valid and valuable, and I think we can address that concern with the existing migration network binding/configs.
To amend my comment in #8 there actually is a libc call we can use to get the "official" name of a host (this is also what `hostname -f` uses), with rigorous fallback that might do it.
In any case we must ensure that the principle and subordinate charm on a single host agree on their name.