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.com<mailto: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://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
