Open Stack

I agree, we should amend it to not run pluggable IPAM as the default for now. When we decide to make it the default, the migration scripts will be needed.

John


On 5/5/15, 1:47 PM, "Salvatore Orlando" <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:

Patch #153236 is introducing pluggable IPAM in the db base plugin class, and default to it at the same time, I believe.

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.

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.
I suggest to not enable it by default, and then consider in L-3 whether we should do this switch.
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.

Salvatore

On 4 May 2015 at 20:11, Pavel Bondar <pbondar at infoblox.com<mailto:pbondar at infoblox.com>> wrote:
Hi,

During fixing failures in db_base_plugin_v2.py with new IPAM[1] I faced
to check-grenade-dsvm-neutron failures[2].
check-grenade-dsvm-neutron installs stable/kilo, creates
networks/subnets and upgrades to patched master.
So it validates that migrations passes fine and installation is works
fine after it.

This is where failure occurs.
Earlier there was an agreement about using pluggable IPAM only for
greenhouse installation, so migrate script from built-in IPAM to
pluggable IPAM was postponed.
And check-grenade-dsvm-neutron validates greyhouse scenario.
So do we want to update this agreement and implement migration scripts
from built-in IPAM to pluggable IPAM now?

Details about failures.
Subnets created before patch was applied does not have correspondent
IPAM subnet,
so observed a lot of failures like this in [2]:
>Subnet 2c702e2a-f8c2-4ea9-a25d-924e32ef5503 could not be found
Currently config option in patch is modified to use pluggable_ipam by
default (to catch all possible UT/tempest failures).
But before the merge patch will be switched back to non-ipam
implementation by default.

I would prefer to implement migrate script as a separate review,
since [1] is already quite big and hard for review.

[1] https://review.openstack.org/#/c/153236
[2]
http://logs.openstack.org/36/153236/54/check/check-grenade-dsvm-neutron/42ab4ac/logs/grenade.sh.txt.gz

- Pavel Bondar

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150506/05328a9e/attachment.html>