Loading…
This event has ended. View the official site or create your own event → Check it out
This event has ended. Create your own
Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.
View analytic
Wednesday, November 6 • 3:40pm - 4:20pm
State of affairs in DB schema migrations

Sign up or log in to save this to your schedule and see who's attending!

Topics to discuss:

1. sqlalchemy-migrate needs a new stable release

Distros use the patched versions of sqlalchemy-migrate to make it compatible with SQLAlchemy 0.8.x releases. The fix is really simple and is already merged to master branch of sqlalchemy-migrate repo on stackforge. We should make a new stable release of sqlalchemy-migrate as a first step to having SQLAlchemy>=0.8.1 in global requirements list.

2. sqlalchemy-migrate is rather old and we'd better switch to alembic as soon as possible (new features, bug fixes, compatibility with new SQLAlchemy versions/etc)

sqlalchemy-migrate had not been maintained for some time, so we start to catch more and more bugs in its compatibility with newer versions of SQLAlchemy (e. g. https://bugs.launchpad.net/nova/+bug/1241038). We could continue to fix it ourselves, but a simpler (and, I believe, the right one) approach would be to switch to Alembic.

3. Problems with switching to Alembic

1) our tests are run on SQLite in-memory DB and we use migrations to obtain the initial DB schema, but Alembic doesn't support ALTER in SQLite on purpose (sqlalchemy-migrate implements it by using a couple of hacks)

so we should use models definitions to generate the initial DB schema for running tests, but

2) we can't use models definitions to generate the initial DB schema right now, because models are out of sync with migrations (so the schema obtained by applying of migration scripts and the one generated from models definitions MAY be different, please see the blueprint below for more information)

and

3) switch to Alembic would mean dropping migrations support on SQLite (and Debian/Ubuntu OpenStack packages maintainers) would not be glad

Blueprints below provide more information on how sqlalchemy-migrate and alembic can live together in Ceilometer + explain out-of-sync problem in details.

(Session proposed by Roman Podolyaka)


Wednesday November 6, 2013 3:40pm - 4:20pm
AWE Level 2, Room 201B

Attendees (41)