Agreed. Not having migrations is a bad idea. There should be a common approach.
Sent from my iPhone On Oct 25, 2011, at 7:32 PM, Jesse Andrews <anotherje...@gmail.com> wrote: > I don't think the debate is whether to do migrations or not. I think > the debate should be: > > Is there more value in not doing it the same way another openstack > project does it? > > If you can use nova's method, then we get closer to having standard > operating procedures for openstack projects... > > On Tue, Oct 25, 2011 at 3:16 PM, Brian Schott > <brian.sch...@nimbisservices.com> wrote: >> It's probably the best approach that doesn't depend on the Django ORM (like >> South). Does anyone use the "experimental" command line migrate to generate >> the migrate script? I always did it by hand. >> http://packages.python.org/sqlalchemy-migrate/ > > I think the nova team looked at south but decided to do it the way > they did for various reasons. It seems like one of those things that > doing the same thing as other openstack projects is probably worth it > from a simplicity point of view... > >> On the dev side, one of the big headaches in nova migrate_repo has been that >> the file numbering by hand meant that competing feature teams that needed to >> incorporate a schema change had to keep bumping the number every time a new >> version file got committed. We talked about relaxing migrate_repo numbering >> rules so that you could create a 999_my_pending_change.py file that didn't >> break the version numbering adjacency checks. I don't know if that >> happened. Otherwise, every time a new file arrived in trunk, we all had to >> manually renumber our development files from 055_x to 056_x... Not a big >> deal, but annoying when you pushed a branch up for review, then it broke >> because something else arrived in the same number slot. > > True - this is an issue in any distributed revision control system. > It is certainly annoying but the value you get out of having > migrations is worth it. > > We could make it so the merge process involved submitting as 999 (and > higher) and the merge bot renumbers if this was a huge issue. > >> On the deploy side, complicated table transforms don't always map well to >> all database backends and I don't think here is any unit testing with >> populated fixtures for data upgrade/downgrade. Don't know if this has been >> an issue in real deployments, but the opportunity for sysadmin excellence is >> certainly there.... > > In my experience many sysadmins don't want to run the migrations in > large custom deployments - they use the migrations as guidelines for > what they need to do. Then write / plan upgrades for themselves. > > Perhaps it would be good to hear from folks working on products that > are more like appliances (like citrix, piston, 4p, ...) > > j > >> Brian >> ------------------------------------------------- >> Brian Schott, CTO >> Nimbis Services, Inc. >> brian.sch...@nimbisservices.com >> ph: 443-274-6064 fx: 443-274-6060 >> >> >> >> >> >> >> On Oct 25, 2011, at 5:45 PM, Ziad Sawalha wrote: >> >> Our schema right now is auto generated from the model using sqlalchemy. >> Whenever we change the model, the generated schema is different for new >> installations but this does not address existing deployments. >> Looking for feedback on how to handle this better: >> anotherjesses >> offered: >> https://github.com/openstack/nova/tree/master/nova/db/sqlalchemy/migrate_repo >> Questions: >> - Has anyone used this on the dev side? >> - Has anyone used this on the deployment/ops side? >> Would love to hear from you how you started it (we have multiple versions of >> our schema out there, so where do we start) and what was the experience >> updating versions. >> Regards, >> Ziad >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
