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" <sorla...@nicira.com > <mailto:sorla...@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 <pbon...@infoblox.com > <mailto:pbon...@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-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
