Open Stack

If we are going to continue to use the "name" API field to populate
metadata for the instance and set the dns_name field of the port, yes.

Really the right answer is to add a hostname field to the nova API
that had the proper validation and IDN support. That way the "name"
field is simple API metadata and not overloaded for multiple purposes.

Michael

On Mon, Nov 30, 2020 at 10:52 AM Sean Mooney <smooney at redhat.com> wrote:
>
> On Mon, 2020-11-30 at 10:55 -0500, Ruby Loo wrote:
> > On Mon, Nov 30, 2020 at 6:56 AM Stephen Finucane <stephenfin at redhat.com>
> > 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"?
> > >
> >
> >  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.
>
> ok based on this we cant outright block fqdns in teh api.
> their use is still undefined but we at least need to provide a deprecation cycle and upgrade procedure
> it we want to remove them though it sound like we need to actully add support which mean we need to agree on the semantics.
>
>
> i have done some testing with designate enabled and use fqdns
>
> http://paste.openstack.org/show/800564/
>
> tl;dr its totally inconsitent and broken in various way but you can boot vmand networking appears to work.
>
> i booted a server wtih the server name test-dns.invalid.dns
> the default domain name for my deploymnent in designate is cloud.seanmooney.info
>
>
> the hostname in the vm is test-dns
>
> ubuntu at test-dns:~$ cat /etc/hostname
> test-dns
>
> ubuntu at test-dns:~$ hostname
> test-dns
>
> however the fqdn is reported as test-dns.cloud.seanmooney.info
>
> ubuntu at test-dns:~$ hostname -f
> test-dns.cloud.seanmooney.info
>
> if we list all fqdns we get
> ubuntu at test-dns:~$ hostname -A
> test-dns.invalid.dns.cloud.seanmooney.info test-dns.invalid.dns.cloud.seanmooney.info
> not that it appends the default designate domain to the server name
>
> looking at the ec2 metadata the server name is appended to the nova dhcp_domain conf option value
>
> "hostname": "test-dns.invalid.dns.novalocal",
>    "instance-action": "none",
>    "instance-id": "i-00000109",
>    "instance-type": "small-multi-numa",
>    "local-hostname": "test-dns.invalid.dns.novalocal",
>    "local-ipv4": "172.20.4.32",
>    "placement": {
>     "availability-zone": "nova"
>    },
>    "public-hostname": "test-dns.invalid.dns.novalocal",
>
>
> and the openstack varient is
> "local-hostname": "test-dns",
>
> so the server has 4 posible hostnames and none of them are server name "test-dns.invalid.dns"
>
> test-dns.invalid.dns does resolve on the host
>
> buntu at test-dns:~$ ping test-dns.invalid.dns
> PING test-dns.invalid.dns(test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619)) 56 data bytes
> 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=1 ttl=64 time=0.039 ms
> 64 bytes from test-dns.invalid.dns.cloud.seanmooney.info (2001:470:1836:1:f816:3eff:fe59:f619): icmp_seq=2 ttl=64 time=0.062 ms
> ^C
> --- test-dns.invalid.dns ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 0.039/0.050/0.062/0.011 ms
> ubuntu at test-dns:~$ nslookup test-dns.invalid.dns
> Server:         127.0.0.53
> Address:        127.0.0.53#53
>
> Non-authoritative answer:
> Name:   test-dns.invalid.dns
> Address: 172.20.4.32
> Name:   test-dns.invalid.dns
> Address: 2001:470:1836:1:f816:3eff:fe59:f619
>
>
> but only because of the dns search path
>
>
> ubuntu at test-dns:~$ cat /etc/resolv.conf
> # This file is managed by man:systemd-resolved(8). Do not edit.
> #
> # This is a dynamic resolv.conf file for connecting local clients to the
> # internal DNS stub resolver of systemd-resolved. This file lists all
> # configured search domains.
> #
> # Run "resolvectl status" to see details about the uplink DNS servers
> # currently in use.
> #
> # Third party programs must not access this file directly, but only through the
> # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
> # replace this symlink by a static file or a different symlink.
> #
> # See man:systemd-resolved.service(8) for details about the supported modes of
> # operation for /etc/resolv.conf.
>
> nameserver 127.0.0.53
> options edns0
> search cloud.seanmooney.info
>
> ubuntu at test-dns:~$ systemd-resolve --status
> Global
>        LLMNR setting: no
> MulticastDNS setting: no
>   DNSOverTLS setting: no
>       DNSSEC setting: no
>     DNSSEC supported: no
>           DNSSEC NTA: 10.in-addr.arpa
>                       16.172.in-addr.arpa
>                       168.192.in-addr.arpa
>                       17.172.in-addr.arpa
>                       18.172.in-addr.arpa
>                       19.172.in-addr.arpa
>                       20.172.in-addr.arpa
>                       21.172.in-addr.arpa
>                       22.172.in-addr.arpa
>                       23.172.in-addr.arpa
>                       24.172.in-addr.arpa
>                       25.172.in-addr.arpa
>                       26.172.in-addr.arpa
>                       27.172.in-addr.arpa
>                       28.172.in-addr.arpa
>                       29.172.in-addr.arpa
>                       30.172.in-addr.arpa
>                       31.172.in-addr.arpa
>                       corp
>                       d.f.ip6.arpa
>                       home
>                       internal
>                       intranet
>                       lan
>                       local
>                       private
>                       test
>
> Link 2 (enp1s0)
>       Current Scopes: DNS
> DefaultRoute setting: yes
>        LLMNR setting: yes
> MulticastDNS setting: no
>   DNSOverTLS setting: no
>       DNSSEC setting: no
>     DNSSEC supported: no
>   Current DNS Server: 172.20.4.2
>          DNS Servers: 172.20.4.2
>                       2001:470:1836:1:f816:3eff:fe7b:583
>           DNS Domain: cloud.seanmooney.info
>
>
> as far as i can tell there is no file or data source that will allow you to see teh server name value
> test-dns.invalid.dns the closest you can get is the instance uuid 9387d654-93eb-41cf-9f59-a6099e0daba1 in the cloud metadata.
>
> so i you are using FQDNs today it does not work in any useful way.
>
> >
> > --ruby
> >
> >
> > > Cheers,
> > > Stephen
> > >
> > > [1] https://launchpad.net/bugs/1581977
> > > [2] https://review.opendev.org/c/openstack/nova/+/764482
> > >
> > >
> > >
>
>
>