Here is a compromise option. The pluggable IPAM will be optionally enabled in Kilo. We could introduce the restriction, but only when pluggable IPAM is enabled. Support for having a tenant with overlapping IP space, along with pluggable IPAM would wait until Liberty, when we can fully implement the "address scope" concept. This concept was discussed during the spec reviews of pluggable IPAM, and is simply adding a first-class object that represents a layer 3 address space. A subnet would belong to a specific scope, and any IP within a scope would be unique. To support the tenant with overlapping space, you would create multiple scopes for that tenant.
This option maintains backward compatibility for existing deployments, while allowing us to improve the model moving forward. John On 3/11/15, 2:22 AM, "Carl Baldwin" <[email protected]> wrote: >On Tue, Mar 10, 2015 at 11:34 AM, Gabriel Bezerra ><[email protected]> wrote: >> Em 10.03.2015 14:24, Carl Baldwin escreveu: >> 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 see your point but yuck! This isn't the place to skimp on >configuration changes. > >Carl > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
