Open Stack

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
> > 
> > 
> >