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 <[email protected]> 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/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 > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
