That does, indeed, appear to be a solution to the problem. Albeit, not an ideal solution. I really hope that this will be resolved in Neutron eventually.
On Wed, Jan 10, 2018 at 5:00 PM, Jonathan Mills <jonmi...@gmail.com> wrote: > Thanks, Flint WALRUS. I will certainly try that. > > On Wed, Jan 10, 2018 at 4:57 PM, Flint WALRUS <gael.ther...@gmail.com> > wrote: > >> As you’re using a L2 network topology and until all of your project use a >> different network you can do: >> >> domain=domain1,10.10.10.0/24 >> domain=domain2,20.20.20.0/24 >> >> Within the dnsmasq-neutron.conf file. >> Of course, restart the neutron-server service once done. >> Le mer. 10 janv. 2018 à 22:40, Jonathan Mills <jonmi...@gmail.com> a >> écrit : >> >>> 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/oca >>> ta/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 >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
