[openstack-dev] [Nova] sqlalchemy-migrate vs alembic for new database

Mike Bayer mbayer at redhat.com
Fri Dec 5 22:17:41 UTC 2014


> On Dec 5, 2014, at 3:14 PM, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
> 
> 
> 
> On 12/5/2014 1:45 PM, Andrew Laski wrote:
>> The cells v2 effort is going to be introducing a new database into
>> Nova.  This has been an opportunity to rethink and approach a few things
>> differently, including how we should handle migrations. There have been
>> discussions for a long time now about switching over to alembic for
>> migrations so I want to ask, should we start using alembic from the
>> start for this new database?
>> 
>> The question was first raised by Dan Smith on
>> https://review.openstack.org/#/c/135424/
>> 
>> I do have some concern about having two databases managed in two
>> different ways, but if the details are well hidden behind a nova-manage
>> command I'm not sure it will actually matter in practice.
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
> 
> I don't have experience with Alembic but I'd think we should use Alembic for the new database unless there is a compelling reason not to. Maybe we need Mike Bayer (or other oslo.db people) to give us an idea of what kinds of problems we might have with managing two databases with two different migration schemes.
> 
> But the last part you said is key for me, if we can abstract it well then hopefully it's not very painful.

sqlalchemy-migrate doesn’t really have a dedicated maintainer anymore, AFAICT.  It’s pretty much on stackforge life support.   So while the issue of merging together a project with migrate and alembic at the same time seems to be something for which there are some complexity and some competing ideas (I have one that’s pretty fancy, but I haven’t spec’ed or implemented it yet, so for now there are “wrappers” that run both), it sort of has to happen regardless.


More information about the OpenStack-dev mailing list