On Mon, 2020-11-30 at 10:55 -0500, Ruby Loo wrote:
On Mon, Nov 30, 2020 at 6:56 AM Stephen Finucane <stephenfin@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@test-dns:~$ cat /etc/hostname test-dns ubuntu@test-dns:~$ hostname test-dns however the fqdn is reported as test-dns.cloud.seanmooney.info ubuntu@test-dns:~$ hostname -f test-dns.cloud.seanmooney.info if we list all fqdns we get ubuntu@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@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@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@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@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