Open Stack

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#L529-L535
[2] https://github.com/openstack/nova/blob/16cabdd10/nova/network/neutron.py#L1599-L1600

> This also came up in another bug report recently, by the way:
> 
>     https://launchpad.net/bugs/1888722
>