Open Stack

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 <jonmills at 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/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
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180110/f9aa37fd/attachment.html>