Open Stack

On 21 April 2015 at 14:25, Guo, Ruijing <ruijing.guo at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150421/724f31a4/attachment.html>