Open Stack

On Mon, Nov 30, 2020 at 2:20 PM Michael Johnson <johnsomor at gmail.com> wrote:
>
> 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.

Yeah, I don't think anyone's going to disagree with this. But this
would be a new microversion, and so cannot be backported to stable
releases.

Our (RedHat's) pickle is what to do in the case of someone wanting to
use domain-like VM names with Neutron DNS integration. Currently what
ends up in Neutron's dns_name field (and in Nova's instance.hostname)
is derived from the VM name, but that derivation allows things that
Neutron doesn't agree are valid - namely, endings in .<number>. I
think Stephen's original question is around modifying how we do that
derivation, and whether starting to transform <name>.<number> into
Server-<UUID> would break anyone.

My proposal would be to just guard that new transformation with a
[workarounds] config option. I know it's lazy and dirty, but as you
pointed out, the real solution is a new API microversion that splits
the VM display name from the hostname/FQDN entirely. The new
[workarounds] option means anyone hitting bug 1581977 can turn it on
fully aware of what's going to happen (namely, ubuntu.04 getting a
hostname of Server-<UUID>), and anyone not affected can carry on as
before.


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