Open Stack

On 1 May 2013 01:16, Dolph Mathews <dolph.mathews at gmail.com> wrote:
>
> 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.

You can land C at any point. Migrations are executed in-order, and the
*code* has to know how to deal with all of A, B and C. In fact, you
probably would land B and C migrations as one commit. So I don't see
how it interacts with releases or iteration at all.

In terms of GC of the migrations, we need to step back for a second;
there are two distinct upgrade paths.
- The release train. E->F->G etc. In this train, deployers step from
release branch to release branch, and we didn't propose making
guarantees about uptime during upgrades for this use case at all. So
it would be valid to smoosh the all the migrations for a whole release
into one, remove all the code awareness for the now deleted
intermediary schemas and make it be a blocking upgrade with downtime.

- The deploying-trunk train. In this train deployers are running trunk
and expecting to deploy new features at high frequency. This is the
primary use case for no-downtime schema changes. I don't recall that
we had a solid answer for when to collapse migrations. Obvious
possibilities are to use a sliding window or tie cleaning up old
intermediary code to releases.

-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services