Re: [openstack-dev] [neutron] neutron DB upgrade
But maybe some component depend on another one. And it would be difficult to test all the components combination. /Yalei From: Guo, Ruijing [mailto:ruijing@intel.com] Sent: Wednesday, April 22, 2015 10:23 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] neutron DB upgrade Thanks for your detail explanation. I agree with you that we still use DB upgrade when fresh installation. Yes. It happened to me that unused vendor DB upgrade failure causes neutron DB upgrade failure. I have little concerns about adding whole DB upgrade in one directory alembic_migrations/versions. It is difficult for devops to debug/workaround the issue. I suggest to separate according to components or enforce file name as Revision_component_desctiption.py. If I don’t use the component and DB for that component upgrade fails, I can safely delete *component*. Thanks, -Ruijing From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Tuesday, April 21, 2015 9:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] neutron DB upgrade On 21 April 2015 at 14:25, Guo, Ruijing ruijing@intel.commailto:ruijing@intel.com wrote: Somebody can help me to understand why neutron DB is needed upgrade even in refresh installation unlike other components. From my understanding, DB upgrade is risky and needed when upgrade. Alembic is a fairly reliable tool for managing DB upgrades. Also there are enough tests in place to ensure the sanity of each db migration and that the DB schema is always in sync with business logic's data model. Release A should have schema A and Release B should have schema B. This will make really difficult doing testing during the development cycle. While all interim migrations added during the release cycle can be squashed into a single migration provided at release time, this action will probably transform a relatively safe process into a risky one, as there will be little time to react to issues introduced by that single migration. Only upgrade A to B need to upgrade DB. This is what happens for most users. However there still are a few which more or less closely follow trunk - that is to say they're not tied to any specific release. Also, this does not apply to developers and CI (which is ultimately one of the principal tools we use to ensure what we deliver is not completely rubbish). In the same time, can we separate neutron DB as vendor DB non-vendor DB? We had vendor or plugin specific migrations until Juno. When he had these kind of conditional migrations doing DB upgrades was very risky. DB schema management has become a lot simpler and safer since we unified the schema. However, as a part of the vendor plugin split out there will be eventually a next step where all vendor-specific tables are moved into their own dbs. Are tables for plugins which are not ML2 causing you any problem? 1. For that case, we can upgrade vendor DB if we use some vendor scenario. 2. we already separate vendor code from neutron code base. Thanks, -Ruijing __ 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] neutron DB upgrade
On 21 April 2015 at 14:25, Guo, Ruijing ruijing@intel.com wrote: Somebody can help me to understand why neutron DB is needed upgrade even in refresh installation unlike other components. From my understanding, DB upgrade is risky and needed when upgrade. Alembic is a fairly reliable tool for managing DB upgrades. Also there are enough tests in place to ensure the sanity of each db migration and that the DB schema is always in sync with business logic's data model. Release A should have schema A and Release B should have schema B. This will make really difficult doing testing during the development cycle. While all interim migrations added during the release cycle can be squashed into a single migration provided at release time, this action will probably transform a relatively safe process into a risky one, as there will be little time to react to issues introduced by that single migration. Only upgrade A to B need to upgrade DB. This is what happens for most users. However there still are a few which more or less closely follow trunk - that is to say they're not tied to any specific release. Also, this does not apply to developers and CI (which is ultimately one of the principal tools we use to ensure what we deliver is not completely rubbish). In the same time, can we separate neutron DB as vendor DB non-vendor DB? We had vendor or plugin specific migrations until Juno. When he had these kind of conditional migrations doing DB upgrades was very risky. DB schema management has become a lot simpler and safer since we unified the schema. However, as a part of the vendor plugin split out there will be eventually a next step where all vendor-specific tables are moved into their own dbs. Are tables for plugins which are not ML2 causing you any problem? 1. For that case, we can upgrade vendor DB if we use some vendor scenario. 2. we already separate vendor code from neutron code base. Thanks, -Ruijing __ 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] neutron DB upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/21/2015 02:25 PM, Guo, Ruijing wrote: Somebody can help me to understand why neutron DB is needed upgrade even in refresh installation unlike other components. refresh installation == minor version upgrade for a stable release? No, it should not require db upgrade, it's forbidden to backport patches that involve db migration to stable releases. From my understanding, DB upgrade is risky and needed when upgrade. Release A should have schema A and Release B should have schema B. Only upgrade A to B need to upgrade DB. In the same time, can we separate neutron DB as vendor DB non-vendor DB? Not sure what you mean. Neutron does not distinguish between deployment scenarios in terms of db schema. It's always the same (at least that's the case since Juno). /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVNkrxAAoJEC5aWaUY1u576fAIAOMjencFLoSVfYv/1sJgds2W 5mPdQM5yMlGHR18fI9FSjA41BItOsPknppl9YtwrxNHN3h8VyTWDkSSQanMBDfgE jkGEP2NG6ZFIfCQHwKTJ8c3VPxPEVBc0k4Nj6qC2mC1Rp4gIqGkmTFuo5xK9jm0g C0qqZzNzh7yag0yKFb6XM/2mkk/DReMIqVJQ3WkIBim8EfAq/CXrZsxkz33mj0wn G9uWtKEnmi0/U2/ZLrNcGSVTiHsj3qtBYSW/cPZOhjPcCAynYJmKcR56ipwe8CXk 3mQcsQWQpeNuW5tX6LMnImDrVdEEnulT2W/2PCZtYgQgTfswfmF/mSr4/s2Ogm4= =yVaY -END PGP SIGNATURE- __ 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] neutron DB upgrade
Somebody can help me to understand why neutron DB is needed upgrade even in refresh installation unlike other components. From my understanding, DB upgrade is risky and needed when upgrade. Release A should have schema A and Release B should have schema B. Only upgrade A to B need to upgrade DB. In the same time, can we separate neutron DB as vendor DB non-vendor DB? 1. For that case, we can upgrade vendor DB if we use some vendor scenario. 2. we already separate vendor code from neutron code base. Thanks, -Ruijing __ 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] neutron DB upgrade
Thanks for your detail explanation. I agree with you that we still use DB upgrade when fresh installation. Yes. It happened to me that unused vendor DB upgrade failure causes neutron DB upgrade failure. I have little concerns about adding whole DB upgrade in one directory alembic_migrations/versions. It is difficult for devops to debug/workaround the issue. I suggest to separate according to components or enforce file name as Revision_component_desctiption.py. If I don’t use the component and DB for that component upgrade fails, I can safely delete *component*. Thanks, -Ruijing From: Salvatore Orlando [mailto:sorla...@nicira.com] Sent: Tuesday, April 21, 2015 9:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] neutron DB upgrade On 21 April 2015 at 14:25, Guo, Ruijing ruijing@intel.commailto:ruijing@intel.com wrote: Somebody can help me to understand why neutron DB is needed upgrade even in refresh installation unlike other components. From my understanding, DB upgrade is risky and needed when upgrade. Alembic is a fairly reliable tool for managing DB upgrades. Also there are enough tests in place to ensure the sanity of each db migration and that the DB schema is always in sync with business logic's data model. Release A should have schema A and Release B should have schema B. This will make really difficult doing testing during the development cycle. While all interim migrations added during the release cycle can be squashed into a single migration provided at release time, this action will probably transform a relatively safe process into a risky one, as there will be little time to react to issues introduced by that single migration. Only upgrade A to B need to upgrade DB. This is what happens for most users. However there still are a few which more or less closely follow trunk - that is to say they're not tied to any specific release. Also, this does not apply to developers and CI (which is ultimately one of the principal tools we use to ensure what we deliver is not completely rubbish). In the same time, can we separate neutron DB as vendor DB non-vendor DB? We had vendor or plugin specific migrations until Juno. When he had these kind of conditional migrations doing DB upgrades was very risky. DB schema management has become a lot simpler and safer since we unified the schema. However, as a part of the vendor plugin split out there will be eventually a next step where all vendor-specific tables are moved into their own dbs. Are tables for plugins which are not ML2 causing you any problem? 1. For that case, we can upgrade vendor DB if we use some vendor scenario. 2. we already separate vendor code from neutron code base. Thanks, -Ruijing __ 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
