[Openstack] database migration cleanup

Dan Prince dprince at redhat.com
Mon Apr 30 15:58:34 UTC 2012



----- Original Message -----
> From: "Monsyne Dragon" <mdragon at RACKSPACE.COM>
> To: "Dan Prince" <dprince at redhat.com>
> Cc: "Sean Dague" <sdague at linux.vnet.ibm.com>, "<openstack at lists.launchpad.net>" <openstack at lists.launchpad.net>
> Sent: Friday, April 27, 2012 1:46:03 PM
> Subject: Re: [Openstack] database migration cleanup
> 
> Even better, what would it take to try using Alembic?
> (http://alembic.readthedocs.org/en/latest/front.html#project-homepage)

>From the Alembic docs site: "Note that Alembic is still in alpha status."

I would guess we'd want the project to be in at least a beta (stable API) state before we committed to using it, etc.

> 
> It's a big improvement over sqlalchemy.  Amongst other things,
> migrations are not numbered, they are linked by dependancy, and run
> in topological-sort order. That there eliminates alot of "my
> migration number got taken... again..." problems.

To be clear Alembic would be a potential replacement for python-migrate. Not Sqlalchemy right? Looks like an interesting project but I'm not convinced it is worth switching over to as our default at this time.


> On Apr 27, 2012, at 10:47 AM, Dan Prince wrote:
> 
> > 
> > 
> > ----- Original Message -----
> >> From: "Sean Dague" <sdague at linux.vnet.ibm.com>
> >> To: openstack at lists.launchpad.net
> >> Sent: Friday, April 27, 2012 10:21:17 AM
> >> Subject: Re: [Openstack] database migration cleanup
> >> 
> >> On 04/26/2012 03:24 PM, Dan Prince wrote:
> >> <snip>
> >>> I think this scheme would support users who follow stable
> >>> releases
> >>> as well as users who follow trunk very closely.
> >>> 
> >>> We talked about this at the conference but I thought this issue
> >>> might be near and dear to some of our end users so it was worth
> >>> discussing on the list.
> >>> 
> >>> What are general thoughts on this approach?
> >> 
> >> Is there any support in sqlalchemy, or related tools, to handle
> >> migrations the way rails does, where a schema file is created at
> >> the
> >> end
> >> of every migration? It would be ideal if we both had a full
> >> migration
> >> history, as well as a short cut at any snap shot to get to the
> >> end.
> > 
> > Ah. Yes, the Rails schema.rb. I looked around for just this sort of
> > thing and didn't find much. Python-migrate has some "experimental"
> > support for generating models and I did make use of that
> > initially. See 'create_model' below:
> > 
> > 
> > [root at nova1 migrate_repo]# python ./manage.py --repository=./
> > --url=mysql://nova:password@localhost/nova
> > Usage: manage.py COMMAND ...
> > 
> >    Available commands:
> >        compare_model_to_db          - compare MetaData against the
> >        current database state
> > 	create                       - create an empty repository at the
> > 	specified path
> > 	create_model                 - dump the current database as a
> > 	Python model to stdout
> > 	db_version                   - show the current version of the
> > 	repository under version control
> > 	downgrade                    - downgrade a database to an earlier
> > 	version
> > 	drop_version_control         - removes version control from a
> > 	database
> > 	help                         - displays help on a given command
> > 	make_update_script_for_model - create a script changing the old
> > 	MetaData to the new (current) MetaData
> > 	manage                       - creates a Python script that runs
> > 	Migrate with a set of default values
> > 	script                       - create an empty change Python
> > 	script
> > 	script_sql                   - create empty change SQL scripts for
> > 	given database
> > 	source                       - display the Python code for a
> > 	particular version in this repository
> > 	test                         - performs the upgrade and downgrade
> > 	command on the given database
> > 	update_db_from_model         - modify the database to match the
> > 	structure of the current MetaData
> > 	upgrade                      - upgrade a database to a later
> > 	version
> > 	version                      - display the latest version
> > 	available in a repository
> > 	version_control              - mark a database as under this
> > 	repository's version control
> > 
> > ----
> > 
> > python-migrate's 'create_model' does not however give you something
> > that exactly matches the schema you'd get by running the all the
> > migrations. So auto generation doesn't appear to be an option
> > right now. It would be nice to contribute python-migrate in this
> > regard and get better support for model generation, etc. Maybe a
> > good long term goal?
> > 
> > Dan
> > 
> > 
> >> 
> >> 	-Sean
> >> 
> >> --
> >> Sean Dague
> >> IBM Linux Technology Center
> >> email: sldague at us.ibm.com
> >> alt-email: sdague at linux.vnet.ibm.com
> >> 
> >> 
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~openstack
> >> Post to     : openstack at lists.launchpad.net
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >> 
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> 
> --
> 	Monsyne M. Dragon
> 	OpenStack/Nova
> 	cell 210-441-0965
> 	work x 5014190
> 
> 




More information about the Openstack mailing list