As you’re using a L2 network topology and until all of your project use a different network you can do:<br><br>domain=domain1,<a href="http://10.10.10.0/24">10.10.10.0/24</a><br>domain=domain2,<a href="http://20.20.20.0/24">20.20.20.0/24</a><br><br>Within the dnsmasq-neutron.conf file.<br>Of course, restart the neutron-server service once done.<br><div class="gmail_quote"><div dir="ltr">Le mer. 10 janv. 2018 à 22:40, Jonathan Mills <<a href="mailto:jonmills@gmail.com">jonmills@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Operators,<div><br></div><div>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:  <a href="https://docs.openstack.org/ocata/networking-guide/config-dns-int.html" target="_blank">https://docs.openstack.org/ocata/networking-guide/config-dns-int.html</a></div><div><br></div><div>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:</div><div><br></div><div><a href="https://bugs.launchpad.net/neutron/+bug/1580588" target="_blank">https://bugs.launchpad.net/neutron/+bug/1580588</a><br></div><div><br></div><div>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.</div><div><br></div><div>Any feedback would be much appreciated!</div><div><br></div><div>Cheers,</div><div><br></div><div>Jonathan Mills</div><div>NASA Center for Climate Simulation (NCCS)</div><div>Goddard Space Flight Center, Greenbelt, MD</div></div>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</blockquote></div>