[openstack-dev] [neutron] [ipam] Migration to pluggable IPAM
salv.orlando at gmail.com
Fri Feb 5 21:03:03 UTC 2016
On 5 February 2016 at 17:58, Neil Jerram <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>> wrote:
> >> On 4 February 2016 at 08:22, John Belamaric
> >> <<mailto:jbelamaric at infoblox.com>jbelamaric at infoblox.com> wrote:
> >> > On Feb 4, 2016, at 11:09 AM, Carl Baldwin <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>> wrote:
> >> >> I am trying to bring more attention to  to make final
> decision on
> >> >> approach to use.
> >> >> There are a few point that are not 100% clear for me at this
> >> >>
> >> >> 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...
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev