On 5 February 2016 at 17:58, Neil Jerram <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>> wrote: > >> > >> > >> > >> On 4 February 2016 at 08:22, John Belamaric > >> <<mailto:jbelama...@infoblox.com>jbelama...@infoblox.com> wrote: > >> > >> > >> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin <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>> 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. > > Sorry if that's unhelpful... > > Neil > > > __________________________________________________________________________ > 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
