<div dir="ltr">Patch #153236 is introducing pluggable IPAM in the db base plugin class, and default to it at the same time, I believe.<div><br></div><div>If the consensus is to default to IPAM driver then in order to satisfy grenade requirements those migrations scripts should be run. There should actually be a single script to be run in a one-off fashion. Even better is treated as a DB migration.</div><div><br></div><div>However, the plan for Kilo was to not turn on pluggable IPAM for default. Now that we are targeting Liberty, we should have this discussion again, and not take for granted that we should default to pluggable IPAM just because a few months ago we assumed it would be default by Liberty.</div><div>I suggest to not enable it by default, and then consider in L-3 whether we should do this switch.</div><div>For the time being, would it be possible to amend patch #153236 to not run pluggable IPAM by default. I appreciate this would have some impact on unit tests as well, which should be run both for pluggable and "traditional" IPAM.</div><div><br></div><div>Salvatore</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 May 2015 at 20:11, Pavel Bondar <span dir="ltr"><<a href="mailto:pbondar@infoblox.com" target="_blank">pbondar@infoblox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
During fixing failures in db_base_plugin_v2.py with new IPAM[1] I faced<br>
to check-grenade-dsvm-neutron failures[2].<br>
check-grenade-dsvm-neutron installs stable/kilo, creates<br>
networks/subnets and upgrades to patched master.<br>
So it validates that migrations passes fine and installation is works<br>
fine after it.<br>
<br>
This is where failure occurs.<br>
Earlier there was an agreement about using pluggable IPAM only for<br>
greenhouse installation, so migrate script from built-in IPAM to<br>
pluggable IPAM was postponed.<br>
And check-grenade-dsvm-neutron validates greyhouse scenario.<br>
So do we want to update this agreement and implement migration scripts<br>
from built-in IPAM to pluggable IPAM now?<br>
<br>
Details about failures.<br>
Subnets created before patch was applied does not have correspondent<br>
IPAM subnet,<br>
so observed a lot of failures like this in [2]:<br>
>Subnet 2c702e2a-f8c2-4ea9-a25d-924e32ef5503 could not be found<br>
Currently config option in patch is modified to use pluggable_ipam by<br>
default (to catch all possible UT/tempest failures).<br>
But before the merge patch will be switched back to non-ipam<br>
implementation by default.<br>
<br>
I would prefer to implement migrate script as a separate review,<br>
since [1] is already quite big and hard for review.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/153236" target="_blank">https://review.openstack.org/#/c/153236</a><br>
[2]<br>
<a href="http://logs.openstack.org/36/153236/54/check/check-grenade-dsvm-neutron/42ab4ac/logs/grenade.sh.txt.gz" target="_blank">http://logs.openstack.org/36/153236/54/check/check-grenade-dsvm-neutron/42ab4ac/logs/grenade.sh.txt.gz</a><br>
<br>
- Pavel Bondar<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>