Open Stack

Thanks, Flint WALRUS.  I will certainly try that.

On Wed, Jan 10, 2018 at 4:57 PM, Flint WALRUS <gael.therond at 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 <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/9ba460e8/attachment.html>