Open Stack

My concern is that we are introducing new objects in Neutron that are
scoped to a tenant and we don't have anything else like that right now. For
example, I can create 100 3-tier topologies (router + 3 subnets/networks)
with duplicated names, CIDRs, etc between all of them and it doesn't matter
if I do it on 100 different tenants or all under the same tenant.

Put a different way, tenants don't mean anything in the Neutron data model.
They are just a tag to use to enforce quotas, policies, and filters on
incoming API requests. Uniqueness shouldn't come from 'x' + tenant_id.

It seems like what is being introduced here is going to fundamentally
change that by forcing the creation of separate tenants to have overlapping
IPs. I think the barrier should be very high to introduce anything that
does that.

Can you elaborate why tenants are used for uniqueness for IPAM instead of
having a separate grouping mechanism?

On Wed, Mar 11, 2015 at 3:24 PM, Ihar Hrachyshka <ihrachys at redhat.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 03/10/2015 06:34 PM, Gabriel Bezerra wrote:
> > Em 10.03.2015 14:24, Carl Baldwin escreveu:
> >> Neutron currently does not enforce the uniqueness, or
> >> non-overlap, of subnet cidrs within the address scope for a
> >> single tenant.  For example, if a tenant chooses to use
> >> 10.0.0.0/24 on more than one subnet, he or she is free to do so.
> >> Problems will arise when trying to connect a router between these
> >> subnets but that is left up to the tenant to work out.
> >>
> >> In the current IPAM rework, we had decided to allow this overlap
> >> in the reference implementation for backward compatibility.
> >> However, we've hit a snag.  It would be convenient to use the
> >> subnet cidr as the handle with which to refer to a previously
> >> allocated subnet when talking to IPAM.  If overlap is allowed,
> >> this is not possible and we need to come up with another
> >> identifier such as Neutron's subnet_id or another unique IPAM
> >> specific ID.  It could be a burden on an external IPAM system --
> >> which does not allow overlap -- to work with a completely
> >> separate identifier for a subnet.
> >>
> >> I do not know of anyone using this capability (or mis-feature)
> >> of Neutron.  I would hope that tenants are aware of the issues
> >> with trying to route between subnets with overlapping address
> >> spaces and would avoid it.  Is this potential overlap something
> >> that we should really be worried about?  Could we just add the
> >> assumption that subnets do not overlap within a tenant's scope?
> >>
> >> An important thing to note is that this topic is different than
> >> allowing overlap of cidrs between tenants.  Neutron will continue
> >> to allow overlap of addresses between tenants and support the
> >> isolation of these address spaces.  The IPAM rework will support
> >> this.
> >>
> >> Carl Baldwin
> >
> >
> > I'd vote for allowing against such restriction, but throwing an
> > error in case of creating a router between the subnets.
> >
> > I can imagine a tenant running multiple instances of an
> > application, each one with its own network that uses the same
> > address range, to minimize configuration differences between them.
> >
>
> I agree with Gabriel on the matter. There is nothing inherently wrong
> about a tenant running multiple isolated network setups that use
> overlapping addresses (as there is nothing wrong about multiple
> tenants doing the same).
>
> There seems to be a value in disallowing overlapping subnets attached
> to the same router though.
>
> All in all, there seems to be no need to limit neutron API just
> because most external IPAM implementation do not seem to care about
> supporting the use case.
>
> It's also an issue that the change proposed is backwards incompatible.
>
> /Ihar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVAMCPAAoJEC5aWaUY1u57d/cH/A+nAuLrNaCPumjlOPJP90c3
> 4oSh0ioxEQw2uBRx1mWvcQle0M1U4Psy5CqIjeHgDhRlCNKB2gAYvm7/lCwZoCw7
> pxLUerfZPFguNKYCUly1MYyo0gorycFgemoHKEFwHboDJfPdGYxdhW8HuemCClOG
> ZSeRzjO2rGaHU8XT+QWgI14UBiAu+XlQHy3UwUKEaffXOnja7noCU99/6d7+6TgF
> 5/RdFhpfn6pcRvLboiquo57w6N3q7moORgrGSMuP8cnMMTxo9/TLie+vMXmLPobB
> YmeG1ar1q0ouGKb6ZG7KokUyl6CdpgowZ6bqetPELjBLIO+uhcsJ6g9NvRl4T9o=
> =WQ3Q
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150311/8ce73845/attachment-0001.html>