Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?
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.commailto: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.commailto: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:unsubscribehttp://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
Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?
On Tue, May 5, 2015 at 11:47 AM, Salvatore Orlando sorla...@nicira.com wrote: I suggest to not enable it by default, and then consider in L-3 whether we should do this switch. I agree. At the least, the switch should be decoupled from that patch. I think decoupling them before merging the patch was the plan all along, it just hasn't happened yet. We should create a new patch dependent on this one to make it the default. This will tee it up for discussion and we should put a hold on that new patch until we can discuss in Liberty-3. I currently lean toward not making it the default in Liberty but we can discuss later. Carl __ 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
Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?
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
Re: [openstack-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?
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 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://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-dev] [Neutron][IPAM] Do we need migrate script for neutron IPAM now?
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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
