Open Stack

Dear Operators,

I have a mix of Mitaka and Pike clusters, all for private clouds, and with
multiple tenants.  I am very interested in having the ability to have
per-network (really, per-tenant) dns_domain.  You would think that this
works, based on the documentation here:
https://docs.openstack.org/ocata/networking-guide/config-dns-int.html

And yes, I have read and re-read that document many times, and carefully
followed its instructions.  I have the 'dns' extension_driver enabled in
ML2.  I have set an alternate value from 'openstacklocal' in neutron.conf.
I am using the neutron dnsmasq processes as my real DNS servers in my VMs
for tenant internal name resolution. (Instance short-name resolution does
work, it's just that the FQDN of every VM is wrong.)  I have created
per-network dns_domain entries in my neutron database.  Nevertheless, it
does not work.  In every tenant, every VM has a dns suffix equal to
whatever I have set for 'dns_domain' in neutron.conf (the global default).
Scouring the web for clues, I've come across this, which seems to describe
my problem:

https://bugs.launchpad.net/neutron/+bug/1580588

Notice that the importance is 'wishlist'.  Wishlist?  I find it surprising
that it is a mere wish to have DNS work as expected.  I'm curious so I'm
asking the community, is this really not working for anyone?  And if it is
not working for anyone else either, is it really not a big deal?  It seems
to me this would pose a rather large problem for any number of use cases.
In my immediate situation, I am deploying VMs onto a provider network that
has a pre-existing Puppet infrastructure, and all the FQDNs are wrong,
which means the generation of Puppet SSL certificates on these VMs is
problematic.

Any feedback would be much appreciated!

Cheers,

Jonathan Mills
NASA Center for Climate Simulation (NCCS)
Goddard Space Flight Center, Greenbelt, MD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180110/b0e62f66/attachment.html>