Open Stack

Ok, sounds good to me.
I'll switch #153236 to  built-in IPAM implementation by default, and pay
additional attention on testing pluggable IPAM routines in this case.

- Pavel

On 06.05.2015 16:50, John Belamaric wrote:
> 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
> 
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>