On Mon, 2020-11-30 at 13:58 +0000, Jeremy Stanley wrote:
On 2020-11-30 11:51:35 +0000 (+0000), Stephen Finucane wrote: [...]
This is more predictable but breaks the ability to use the instance name as a FQDN. Such usage is something I'm told we've never supported, but I'm concerned that there are users out there who are relying on this all the same and I'd like to get a feel for whether this is the case first.
So, the question: does anyone currently rely on this inadvertent "feature"? [...]
Just to be clear because I'm not entirely sure I follow the question: Are you asking whether users rely on being able to set FQDNs as instance names? Or are you asking whether users rely on Neutron setting those instance names automatically as DNS names?
If it's the first, then yes lots of people (including my personal servers, as well as all of the control plane infrastructure for the OpenDev Collaboratory) enter the canonical DNS names of servers as their instance names. We don't rely on any direct DNS integration in our providers, but we do manually match instance names with address records in the relevant DNS zones we maintain.
The two questions are unfortunately intertwined. The same information - 'instance.hostname' - is used both by cloud-init (via the metadata service/config drive) to initialize the instance name [1] and by neutron when attaching ports on a network with DNS integration [2]. Unless we decouple those, any change will affect both. Stephen [1] https://github.com/openstack/nova/blob/16cabdd10/nova/api/metadata/base.py#L... [2] https://github.com/openstack/nova/blob/16cabdd10/nova/network/neutron.py#L15...
This also came up in another bug report recently, by the way: