[openstack-dev] [neutron] [designate] multi-tenancy in Neutron's DNS integration

Mike Spreitzer mspreitz at us.ibm.com
Mon May 9 19:50:15 UTC 2016


"Hayes, Graham" <graham.hayes at hpe.com> wrote on 05/09/2016 03:00:34 PM:

> From: "Hayes, Graham" <graham.hayes at hpe.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 05/09/2016 03:05 PM
> Subject: Re: [openstack-dev] [neutron] [designate] multi-tenancy in 
> Neutron's DNS integration
> 
> On 09/05/2016 19:21, Mike Spreitzer wrote:
> > I just read
> > 
http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.htmland
> , unless
> > I missed something, it seems to be describing something that is not
> > multi-tenant.  I am focused on FQDNs for Neutron Ports.  For those, 
only
> > the "hostname" part (the first label, in official DNS jargon) is
> > controllable by the Neutron user, the rest of the FQDN is fixed in
> > Neutron configuration.  Have I got that right?  If so then I am
> > surprised.  I would have expected something that isolates tenants
> > (projects) from one another.  Is there any interest in such a thing?
> >
> > Thanks,
> > Mike
> 
> ...
> 
> If you have per-project networks the integration can be done on a
> project by project basis, with floating IPs assigned the name from
> the port and the zone from the private network.

Oh, right, the network gets to specify the rest of the FQDN.  In my case I 
am interested in Neutron Ports on tenant networks.  So with a per-port 
"hostname" (first label) and per-network "domain" (rest of the labels), I 
would get separation between tenants --- at least in the sense that there 
is no overlap in FQDNs.  Will this work for private tenant networks?

The other part of separation is that I do not want one tenant to even be 
able to look up FQDNs that belong to another tenant.  Is this prohibition 
possible today?  If not, is anyone else interested in it?

Thanks,
Mike



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160509/92795a0a/attachment.html>


More information about the OpenStack-dev mailing list