Open Stack

On 07/26/2013 01:55 PM, Doug Hellmann wrote:
> It makes sense, though, if the data is going to be (potentially) 
> coming from separate databases. Is that any different for 
> sqlalchemy-migrate?
>
> As far as tracking the separate migrations for the different schemas, 
> that's handled by running "alembic init" for each schema to create a 
> different environment. The environments should then have unique 
> "version_table" values defined in the alembic.ini that the versions of 
> each schema can be tracked separately. I suggest 
> alembic_version_${schema_owner} where schema_owner is the subset of 
> the schema (i.e., policy, tokens, or identity), or the extension name.

It think that this will require enough of a change that I would like to 
do it in Icehouse, and have a detailed blueprint written up for it.
>
>
> On Fri, Jul 26, 2013 at 1:42 PM, Dolph Mathews 
> <dolph.mathews at gmail.com <mailto:dolph.mathews at gmail.com>> wrote:
>
>     Based on the docs, it looks like you need to start with separate
>     sqlalchemy engines with their own metadata instances for each
>     environment you want to migrate. That sounds like a significant
>     refactor from where we are today (everything shares
>     keystone.common.sql.core.ModelBase).
>
>
>     On Thu, Jul 25, 2013 at 10:41 PM, Morgan Fainberg <m at metacloud.com
>     <mailto:m at metacloud.com>> wrote:
>
>         +1 to getting the multiple repos in place.  Moving to Alembric
>         later on in H or even as the first commit of I should meet our
>         goals to be on Alembric in a reasonable timeframe.  This also
>         allows us to ensure we aren't rushing the work to get our
>         migration repos over to Alembric.
>
>         I think that allowing the extensions to have their own repos
>         sooner is better, and if we end up with an extension that has
>         more than 1 or 2 migrations, we have probably accepted code
>         that is far from fully baked (and we should evaluate how that
>         code made it in).
>
>         I am personally in favor of making the first commit of
>         Icehouse (barring any major issue) the point in which we move
>         to Alembric.  We can be selective in taking extension
>         modifications that add migration repos if it is a major
>         concern that moving to Alembric is going to be really painful.
>
>         Cheers,
>         Morgan Fainberg
>
>         On Thu, Jul 25, 2013 at 7:35 PM, Adam Young <ayoung at redhat.com
>         <mailto:ayoung at redhat.com>> wrote:
>
>             I've been looking into Alembic support.  It seems that
>             there is one thing missing that I was counting on:
>              multiple migration repos. It might be supported, but the
>             docs are thin, and reports vary.
>
>             In the current Keystone implementation, we have a table
>             like this:
>             mysql> desc migrate_version;
>             +-----------------+--------------+------+-----+---------+-------+
>             | Field           | Type         | Null | Key | Default |
>             Extra |
>             +-----------------+--------------+------+-----+---------+-------+
>             | repository_id   | varchar(250) | NO   | PRI | NULL    |
>                   |
>             | repository_path | text         | YES  |     | NULL    |
>                   |
>             | version         | int(11)      | YES  |     | NULL    |
>                   |
>             +-----------------+--------------+------+-----+---------+-------+
>
>
>             Right now we only have one row in there:
>
>              keystone      |
>             /opt/stack/keystone/keystone/common/sql/migrate_repo |       0
>
>
>             However, we have been lumping all of our migrations
>             together into a singel repo, and we are just now looking
>             to sort them out.  For example, Policy, Tokens, and
>             Identity do not really need to share a database.  As such,
>             they could go into separate migration repos, and it would
>             keep changes to one from stepping on changes to another,
>             and avoiding the continuous rebasing problem we currently
>             have.
>
>             In addition, we want to put each of the extensions into
>             their own repos.  This happens to be an important time for
>             that, as we have three extensions coming in that need SQL
>             repos:  OAuth, KDS, and Attribute Mapping.
>
>             I think we should delay moving Keystone to Alembic until
>             the end of Havana, or as the first commit in Icehouse.
>              That way, we have a clean cut over point. We can decide
>             then whether to backport the Extnesion migrations or leave
>             them under sql_alchemy migrations. Mixing the two
>             technologies side by side for a short period of time is
>             going to be required, and I think we need to have a clear
>             approach in place to avoid a mess.
>
>             _______________________________________________
>             OpenStack-dev mailing list
>             OpenStack-dev at lists.openstack.org
>             <mailto:OpenStack-dev at lists.openstack.org>
>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>     -- 
>
>     -Dolph
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130726/28db9c19/attachment-0001.html>