[ops][nova][designate] Does anyone rely on fully-qualified instance names?

Ruby Loo opensrloo at gmail.com
Mon Nov 30 15:55:28 UTC 2020

On Mon, Nov 30, 2020 at 6:56 AM Stephen Finucane <stephenfin at redhat.com>

> When attaching a port to an instance, nova will check for DNS support in
> neutron
> and set a 'dns_name' attribute if found. To populate this attribute, nova
> uses a
> sanitised version of the instance name, stored in the instance.hostname
> attribute. This sanitisation simply strips out any unicode characters and
> replaces underscores and spaces with dashes, before truncating to 63
> characters.
> It does not currently replace periods and this is the cause of bug 1581977
> [1],
> where an instance name such as 'ubuntu20.04' will fail to schedule since
> neutron
> identifies '04' as an invalid TLD.
> The question now is what to do to resolve this. There are two obvious paths
> available to us. The first is to simply catch these invalid hostnames and
> replace them with an arbitrary hostname of format 'Server-{serverUUID}'.
> This is
> what we currently do for purely unicode instance names and is what I've
> proposed
> at [2]. The other option is to strip all periods, or rather replace them
> with
> hyphens, when sanitizing the instance name. 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"?

 I took a look and we (at Verizon Media) have users that create instances
with fqdn-like names (VMs and BMs). I didn't look to see how many instances
have such names, but we have tens of thousands of instances and eyeballing
one of our clusters, > 90% of them have such names.


> Cheers,
> Stephen
> [1] https://launchpad.net/bugs/1581977
> [2] https://review.opendev.org/c/openstack/nova/+/764482
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20201130/3ce37c1e/attachment.html>

More information about the openstack-discuss mailing list