Open Stack

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.
stripping out the unicode is actully incorrect behavior.
hostname are allowed to contain unicode caraters. the asci subset is recommended but
i would find that transfromation itself to be a bug in the implemation.
its certenly not guarenteed to happen in the api and is not documented so it is not something
people shoudl rely on in any way.
> 
> 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"?

the other option is to return a 400 bad request and not do magic in the api.
i would stongly prefer to not transform the users input in any way and require that they pass valid
hostname which is what our current api constratit is and always has been.

any usage of an FQDN previously was undfined behavior that may or may not have workd but was never actully
allowed. i personally dont consider https://launchpad.net/bugs/1581977 to be a valid but outside of the
fact we are not returning a 400 when you pass an FQDN. to do eather feature you describe above you would really need a spec if you want
this to be part of the api contract as right now any sanitization or transfromation we do right now are not part fo the api garunetees.
> 
> Cheers,
> Stephen
> 
> [1] https://launchpad.net/bugs/1581977
> [2] https://review.opendev.org/c/openstack/nova/+/764482
> 
>