Open Stack

Excerpts from Mike Bayer's message of 2015-05-16 19:45:47 -0400:
> 
> On 5/16/15 10:05 AM, Doug Hellmann wrote:
> > Excerpts from Mike Bayer's message of 2015-05-15 13:13:39 -0400:
> >> On 5/15/15 9:31 AM, Doug Hellmann wrote:
> >>> This seems more complicated than needed. If we just stop writing the
> >>> sqlalchemy-migrate scripts and don't change them, then for 1 cycle we
> >>> have to run both sets of migrations and after that we can just run
> >>> alembic.
> >> Then we have a forever-in-perpetuity dependency on SQLAlchemy-Migrate
> >> which must be maintained forever for to maintain compatibility with all
> >> new SQLAlchemy, oslo.db, etc. releases, despite it never being used for
> >> anythine new, because it will be impossible to install an Openstack
> >> application without running through the first set of migrate scripts first.
> > The oslo.db team is also doing work to make it possible to initialize a
> > database without running the migrations. We might need one or two to
> > insert some data, but I thought we were trying to ensure that was done
> > with commands rather than migration scripts. If not, we should be able
> > to reduce the number of migrations we eventually have to port.
> >
> >> The SQLAlchemy-Migrate dependency must be dropped and the project has to
> >> be EOL'ed at some point.   Leaving it in is definitely the more
> >> complicated alternative.
> > Yeah, I wasn't proposing that we keep it forever.
> 
> This doesn't answer the key question.  An application is deployed at 
> Juno, it has a sqlalchemy_migrate table and its on Migrate version 
> "X".   The Liberty version of the code does not use Migrate.  How to 
> upgrade from Juno to Liberty?    Kilo migration is required?

Do we support skipping versions now?

> I really would prefer porting of sqlalchemy-migrate files as an option, 
> because I can do this for projects very easily.   The calling styles are 
> not very different and Alembic's is also a lot more succinct as you 
> don't have to spell out a whole Table to add a column or constraint.   
> Also, as an upstream project Alembic deserves to have a clean upgrade 
> path for projects that want to port from sqlalchemy-migrate to alembic, 
> so this is work that is worth doing in any case.

OK, I'm not saying *don't* do that, just that in the past we have
resisted the idea of changing migration scripts and so we were
looking for a path that didn't require touching all of them. If
there is consensus that it's OK to re-create the migrations using
alembic, then I think it's fine to do that.

Doug