<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 February 2016 at 17:58, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/02/16 16:31, Pavel Bondar wrote:<br>
> On 05.02.2016 12:28, Salvatore Orlando wrote:<br>
>><br>
>><br>
>> On 5 February 2016 at 04:12, Armando M. <<a href="mailto:armamig@gmail.com">armamig@gmail.com</a><br>
</span><span class="">>> <mailto:<a href="mailto:armamig@gmail.com">armamig@gmail.com</a>>> wrote:<br>
>><br>
>><br>
>><br>
>>     On 4 February 2016 at 08:22, John Belamaric<br>
</span>>>     <<mailto:<a href="mailto:jbelamaric@infoblox.com">jbelamaric@infoblox.com</a>><a href="mailto:jbelamaric@infoblox.com">jbelamaric@infoblox.com</a>> wrote:<br>
>><br>
>><br>
>>         > On Feb 4, 2016, at 11:09 AM, Carl Baldwin <<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a> <mailto:<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>>> wrote:<br>
<span class="">>>         ><br>
>>         > On Thu, Feb 4, 2016 at 7:23 AM, Pavel Bondar <<a href="mailto:pbondar@infoblox.com">pbondar@infoblox.com</a> <mailto:<a href="mailto:pbondar@infoblox.com">pbondar@infoblox.com</a>>> wrote:<br>
>>         >> I am trying to bring more attention to [1] to make final decision on<br>
>>         >> approach to use.<br>
>>         >> There are a few point that are not 100% clear for me at this point.<br>
>>         >><br>
>>         >> 1) Do we plan to switch all current clouds to pluggable ipam<br>
>>         >> implementation in Mitaka?<br>
<br>
</span>I possibly shouldn't comment at all, as I don't know the history, and<br>
wasn't around when the fundamental design decisions here were being made.<br>
<br>
However, it seems a shame to me that this was done in a way that needs a<br>
DB migration at all.  (And I would have thought it possible for the<br>
default pluggable IPAM driver to use the same DB state as the<br>
non-pluggable IPAM backend, given that it is delivering the same<br>
semantics.)  Without that, I believe it should be a no-brainer to switch<br>
unconditionally to the pluggable IPAM backend.<br></blockquote><div><br></div><div>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.</div><div>Pavel has all the details, but after careful considerations we decided to adopt a specular model with different db tables.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sorry if that's unhelpful...<br>
<span class="HOEnZb"><font color="#888888"><br>
        Neil<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>