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 <ihrac...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
