John, I think our proposals fit together nicely. This thread is about allowing overlap within a pool. I think it is fine for an external IPAM driver to disallow such overlap for now. However, the reference implementation must support it for backward compatibility and so my proposal will account for that.
The consequence is that your driver will receive the subnet_id as a parameter to get_subnet. It is free to ignore this parameter. I'd still like to hear from Salvatore on this before I update the interface. Carl On Wed, Mar 11, 2015 at 11:08 AM, John Belamaric <[email protected]> wrote: > On 3/12/15, 12:46 AM, "Carl Baldwin" <[email protected]> wrote: > > >>When talking with external IPAM to get a subnet, Neutron will pass >>both the cidr as the primary identifier and the subnet_id as an >>alternate identifier. External systems that do not allow overlap can >> > > Recall that IPAM driver instances are associated with a specific subnet > pool. As long as we do not allow overlap within a *pool* this is not > necessary. The pool will imply the scope (currently implicit, with one per > tenant), which the driver/external system would use to differentiate the > CIDR. As I mentioned in an earlier email, this would introduce the > uniqueness constraint in Kilo, but only when pluggable IPAM is enabled. > > John > > > > > __________________________________________________________________________ > 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
