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/a... [2] https://github.com/openstack/nova/blob/stable/train/nova/network/neutronv2/a... [3] https://docs.openstack.org/api-ref/network/v2/index.html?expanded=update-por... On Thu, Dec 3, 2020 at 12:20 PM Stephen Finucane <stephenfin@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....
Cheers, Stephen
[1] https://launchpad.net/bugs/1581977 [2] https://review.opendev.org/c/openstack/nova/+/764482