Open Stack

On 06.02.2016 00:03, Salvatore Orlando wrote:
>
>
> On 5 February 2016 at 17:58, Neil Jerram <Neil.Jerram at metaswitch.com
> <mailto:Neil.Jerram at metaswitch.com>> wrote:
>
>     On 05/02/16 16:31, Pavel Bondar wrote:
>     > On 05.02.2016 12:28, Salvatore Orlando wrote:
>     >>
>     >>
>     >> On 5 February 2016 at 04:12, Armando M. <armamig at gmail.com
>     <mailto:armamig at gmail.com>
>     >> <mailto:armamig at gmail.com <mailto:armamig at gmail.com>>> wrote:
>     >>
>     >>
>     >>
>     >>     On 4 February 2016 at 08:22, John Belamaric
>     >>     <<mailto:jbelamaric at infoblox.com
>     <mailto:jbelamaric at infoblox.com>>jbelamaric at infoblox.com
>     <mailto:jbelamaric at infoblox.com>> wrote:
>     >>
>     >>
>     >>         > On Feb 4, 2016, at 11:09 AM, Carl Baldwin
>     <carl at ecbaldwin.net <mailto:carl at ecbaldwin.net>
>     <mailto:carl at ecbaldwin.net <mailto:carl at ecbaldwin.net>>> wrote:
>     >>         >
>     >>         > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar
>     <pbondar at infoblox.com <mailto:pbondar at infoblox.com>
>     <mailto:pbondar at infoblox.com <mailto:pbondar at infoblox.com>>> wrote:
>     >>         >> I am trying to bring more attention to [1] to make
>     final decision on
>     >>         >> approach to use.
>     >>         >> There are a few point that are not 100% clear for me
>     at this point.
>     >>         >>
>     >>         >> 1) Do we plan to switch all current clouds to
>     pluggable ipam
>     >>         >> implementation in Mitaka?
>
>     I possibly shouldn't comment at all, as I don't know the history, and
>     wasn't around when the fundamental design decisions here were
>     being made.
>
>     However, it seems a shame to me that this was done in a way that
>     needs a
>     DB migration at all.  (And I would have thought it possible for the
>     default pluggable IPAM driver to use the same DB state as the
>     non-pluggable IPAM backend, given that it is delivering the same
>     semantics.)  Without that, I believe it should be a no-brainer to
>     switch
>     unconditionally to the pluggable IPAM backend.
>
>
> This was indeed the first implementation attempt that we made, but it
> failed spectacularly as we wrestled with different foreign key
> relationships in the original and new model.
> Pavel has all the details, but after careful considerations we decided
> to adopt a specular model with different db tables.
Yeah, we had this chicken and egg problem on subnet creation.

On the one hand, ipam driver create_subnet has to be called *before*
creating neutron subnet.
Because for AnySubnetRequest ipam driver is responsible for selecting
cidr for subnet.

On the other hand, during ipam driver create_subnet call availability
ranges has to be created,
but they are linked with neutron subnet using foreign key (with
allocation pools in the middle).
So availability ranges could not be created before neutron subnet due to
FK constraint in old tables.

To solve this chicken and egg problem it was decided to use tables for
reference driver that have no FK to neutron subnet.
And it allowed to call ipam driver create_subnet (and create
availability ranges) before creating neutron subnet.
>  
>
>
>     Sorry if that's unhelpful...
>
>             Neil
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160208/4bbd4153/attachment-0001.html>