Open Stack

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 <anotherjesse at 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.schott at 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.schott at 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 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
>> 
>>