openstack team mailing list archive

[Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx>]

Thanks, pvo. This looks like good. We'd like to follow what other projects do. Has there been any feedback on this BP? Will this be "the way" to handle things in OpenStack?

The easiest way for us to handle this now for schema migrations to Keystone is to follow Jesse's suggestion and use SQL Alchemy migrate_repo. We'll do that for schema changes currently in our branches and will work towards adopting the BP above.

Z



From: Paul Voccio <paul.voccio@xxxxxxxxxxxxx<mailto:paul.voccio@xxxxxxxxxxxxx>>
Date: Tue, 25 Oct 2011 19:33:57 -0500
To: Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx<mailto:brian.schott@xxxxxxxxxxxxxxxxxx>>, Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx<mailto:ziad.sawalha@xxxxxxxxxxxxx>>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] Handling Schema Changes in Keystone

There is a BP out for how to handle continuious delivery and db upgrades within Nova. It does address some of the issues that keystone may face but feedback on the doc would be appreciated.

https://blueprints.launchpad.net/nova/+spec/deployability-improvements

pvo

From: Brian Schott <brian.schott@xxxxxxxxxxxxxxxxxx<mailto:brian.schott@xxxxxxxxxxxxxxxxxx>>
Date: Tue, 25 Oct 2011 18:16:30 -0400
To: Ziad Sawalha <ziad.sawalha@xxxxxxxxxxxxx<mailto:ziad.sawalha@xxxxxxxxxxxxx>>
Cc: "openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>" <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] Handling Schema Changes in Keystone

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/

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.

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....

Brian

-------------------------------------------------
Brian Schott, CTO
Nimbis Services, Inc.
brian.schott@xxxxxxxxxxxxxxxxxx<mailto: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<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp