openstack team mailing list archive

[Jesse Andrews <anotherjesse@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>