Open Stack

On Mon, Apr 29, 2013 at 3:48 PM, Robert Collins
<robertc at robertcollins.net>wrote:

> There were I think 5? 6? sessions on this general topic at the summit.
>
> https://etherpad.openstack.org/HavanaNoDowntimeDBMigrations is the
> session I coordinated; where Johannes & Mark Wash volunteered to put
> together the basic infrastructure for OpenStack going forward.
>
> We captured several key constraints:
>  * one deploy of new code : distributors cannot depend on lots of little
> steps
>   * <=5 seconds downtime with the database on each migration applied
>   * Stay HA during the entire period
>   * work with mysql 5.1 in the sense of can install/deploy etc.
> no-downtime configurations can require very recent versions of the DB
> (e.g. MySQL 5.5 and above)
>
> And a basic design:
>
> Basic design:
>  * Running foo db-sync will apply migrations in no-downtime fashion
>  * Migrations may be expand-contract, or in-place depending on
> anticipated data-size
>  * Abstraction layer for dealing with different HA configurations
>  * Code talking to the DB will know how to deal with all intermediary
> versions of the DB
>

If we need to support "all" intermediary versions forever, then schema
migrations aren't exactly useful. So, how long do we need to maintain
support for intermediary migrations?

  A -> B -> C

In other words, if patch A introduces intermediary schema support, patch B
is a schema migration, and patch C removes legacy schema support, when can
patch C land? Next milestone? Next release?

(A and B could be the same commit, but I separated them for illustration)

In my opinion, this makes the timing-based releases much more difficult, as
it chokes the iteration process and makes swift's cycle much more appealing.


>  * Rollup migrations and cleanup legacy code on regular basis - e.g.
> once per release.
>
> IIRC glance was going to be the guinea pig, with code migrating from
> there to oslo once it starts to mature.
>
> Cheers,
> Rob
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Cloud Services
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130430/29c2e0b1/attachment.html>