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?
yes stephen was asking whether users rely on being able to set
> FQDNs as instance 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.
> 
so that has never actully been supported, the server name has to be a hostname not a FQDN.
any use of a an fqdn has never been intended to be supproted.

the fact it every worked is a result of incorerct sanitasation in the api which should have rejected it.
the sanitisation code was orginally added to adress https://bugs.launchpad.net/nova/+bug/1495388 by try an munge server names into valid hostnames.
https://github.com/openstack/nova/commit/bc6f30de953303604625e84ad2345cfb595170d2
we could extend it but if we really want to support FQDN that really feals like an new feature that would require an api microversion
not a backportable bug fix.

that bugfix is also not really correct
'哈哈哈' which was the dislpayname that resulted in an empty host name is not invalid.
https://tools.ietf.org/html/rfc5890 and the related docs which discirbes Internationalized Domain Names for Applications
covers the use of unicode in domain names. granted back in 2014 our unicode support in openstack was not great but
longterm we should allow internatalisted hostname that is out of scope of this converation however.


wide use coudl temper that persepctive if suffince exising misuse of the api exists that we need to standarise that use.
techinally you can set an fqdn in /etc/hostname but its discuraged 

https://www.freedesktop.org/software/systemd/man/hostname.html
   " The hostname may be a free-form string up to 64 characters in length; however, it is recommended that it consists only of 7-bit ASCII lower-case
   characters and no spaces or dots, and limits itself to the format allowed for DNS domain name labels, even though this is not a strict requirement."
   

https://www.freedesktop.org/wiki/Software/systemd/hostnamed/

   "
       Generate a single DNS label only, not an FQDN. That means no dots allowed. Strip them, or replace them by "-".
       It's probably safer not to use any non-ASCII chars, even if DNS allows this in some way these days. In fact, restrict your charset to a-zA-Z0-9, -
   . Strip other chars, or try to replace them in some smart way with chars from this set, for example "ä" → "ae" and suchlike, and use "-" as
   replacement for all kinds of punctuation chars or spaces.
       Try to avoid creating repeated "-", as well as "-" as the first or last char.
       Limit the hostname to 63 chars, which is the length of a DNS label
       If after stripping special chars the empty string is the result, you can pass this as-is to hostnamed in which case it will automatically make
   "localhost" out of this.
       It probably is a good idea to replace uppercase by lowercase chars
   "
   
if we are to munge the host server name to create the hostname the conventional approch woudl be striping  '.' and replacing it with "-"
if we choose to support FQDNs we need to ensure that any server name that is set as an FQDN is handeled explcitly and we do not add the dhcp_domain
name to it when genreating the server metadata. we also proably need to strip the domain from it to have /etc/hostname correctly set to just the host
name.

converting the name to server-<server-uuid> would work but it might be surprisign to some that expect the hostname in the server to match the server
name which is why i prefer the 400 error for invalid input.

regardless of what we choose however we should docuemtn this behavior as we dont document it at all.



>  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.
> 
> This also came up in another bug report recently, by the way:
> 
>     https://launchpad.net/bugs/1888722
>