Open Stack

> Greetings,
> 
> One of the features we had on the roadmap for Grizzly was the ability
> to
> backport DB migrations to stable/grizzly after the release if
> necessary.
>  The blueprint became a Havana blueprint, because the implementation
> turned out to just reserve a range of migrations numbers at the
> beginning of Havana development.
> 
>     https://blueprints.launchpad.net/nova/+spec/backportable-db-migrations
>     https://review.openstack.org/#/c/23759/
> 
> I wanted to make sure everyone was aware of this when doing
> reviews of future db migrations.  It means that we must make
> sure that migrations added for Havana are idempotent.  That way
> it should be safe to backport them.  

This is great progress, but one potential nit just occurred to me ...

It relates to the now-traditional compaction of adjacent nova migrations
at release time.

Since stable/grizzly will live on post-havana, and say the reserved
placeholder range of slots 162-171 haven't all been used, would we want
to keep the option open for security fixes with associated migrations
to be backported to stable/grizzly *after* havana is released?

If so, wouldn't that preclude doing the migration compaction at 
havana release time?

Cheers,
Eoghan

> When someone upgrades from
> a stable release that included backportable migrations, they're
> going to get the same migration again at a higher number.
> 
> Thanks!
> 
> --
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>