Open Stack

So coming in very late here with a more... radical? idea. This is just
brainstorming, but here it goes:

Neutron explodes when we update the port with an invalid `dns_name`
here [1]. The request we send in [1] is populated here [2]. So... why
not just *not* do that? IOW, the port will not have a `dns_name` set
at all by Nova when we create the VM, and users can use Neutron's
port-update API [3] to set the hostname they desire. That way, if
Neutron does return a BadRequest, it will really be because the fqdn
is invalid, not because Nova tried to be "smart".

[1] https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1138
[2] https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/api.py#L1494
[3] https://docs.openstack.org/api-ref/network/v2/index.html?expanded=update-port-detail#update-port

On Thu, Dec 3, 2020 at 12:20 PM Stephen Finucane <stephenfin at redhat.com> wrote:
>
> On Mon, 2020-11-30 at 11:51 +0000, Stephen Finucane wrote:
> > 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"?
>
> Thanks to everyone who replied to this. We discussed this in today's nova
> meeting [1] and decided we're okay with changing how we generate instance names,
> and that we can backport this since there are no guarantees made in either the
> documentation or API reference as to what a instance's hostname will be and
> existing instance's won't see their hostname change. There are two options
> available to us:
>
>  * Replace periods with dashes
>
>    This has the best results for people that are naming their instance with
>    FQDNs, since the hostname looks sane.
>
>    'test-instance.mydomain.org' -> 'test-instance-mydomain-org'
>    'ubuntu18.04' -> 'ubuntu18-04'
>
>  * Strip everything after the first period
>
>    This has the best results for everyone else, since the hostname better
>    reflects the original display name.
>
>    'test-instance.mydomain.org' -> 'test-instance'
>    'ubuntu18.04' -> 'ubuntu18'
>
> If anyone has strong feeling on either approach, please let us know. If not,
> we'll duke this out ourselves on #openstack-nova next week.
>
> Also, as an aside, I think we all realize that long term, the best solution for
> this would probably be a API change. This would allow us to add an 'openstack
> server create --hostname' parameter that is correctly validated against the
> various RFCs. I'm not currently planning to work on this but I'd be happy to
> assist anyone that was interested in doing so.
>
> Cheers,
> Stephen
>
> [1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-12-03-16.00.log.txt
>
> > Cheers,
> > Stephen
> >
> > [1] https://launchpad.net/bugs/1581977
> > [2] https://review.opendev.org/c/openstack/nova/+/764482
> >
>
>
>