On 06.02.2016 00:03, Salvatore Orlando wrote: > > > On 5 February 2016 at 17:58, Neil Jerram <neil.jer...@metaswitch.com > <mailto:neil.jer...@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. <arma...@gmail.com > <mailto:arma...@gmail.com> > >> <mailto:arma...@gmail.com <mailto:arma...@gmail.com>>> wrote: > >> > >> > >> > >> On 4 February 2016 at 08:22, John Belamaric > >> <<mailto:jbelama...@infoblox.com > <mailto:jbelama...@infoblox.com>>jbelama...@infoblox.com > <mailto:jbelama...@infoblox.com>> wrote: > >> > >> > >> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin > <c...@ecbaldwin.net <mailto:c...@ecbaldwin.net> > <mailto:c...@ecbaldwin.net <mailto:c...@ecbaldwin.net>>> wrote: > >> > > >> > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar > <pbon...@infoblox.com <mailto:pbon...@infoblox.com> > <mailto:pbon...@infoblox.com <mailto:pbon...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
