<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 21 April 2015 at 14:25, Guo, Ruijing <span dir="ltr"><<a href="mailto:ruijing.guo@intel.com" target="_blank">ruijing.guo@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Somebody can help me to understand why neutron DB is needed upgrade even in refresh installation unlike other components.<br>
<br>
>From my understanding,  DB upgrade is risky and needed when upgrade.<br></blockquote><div><br></div><div>Alembic is a fairly reliable tool for managing DB upgrades.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Release A should have schema A and Release B should have schema B.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Only upgrade A to B need to upgrade DB.<br></blockquote><div><br></div><div>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.</div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In the same time,  can we separate neutron DB as vendor DB & non-vendor DB?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div>Are tables for plugins which are not ML2 causing you any problem?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
1.  For that case, we can upgrade vendor DB if we use some vendor scenario.<br>
<br>
2. we already separate vendor code from neutron code base.<br>
<br>
Thanks,<br>
-Ruijing<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>