Open Stack

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.


On Fri, Jul 26, 2013 at 1:42 PM, Dolph Mathews <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> 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> 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 <OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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
>>
>>
>
>
> --
>
> -Dolph
>
> _______________________________________________
> 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/5672d8c2/attachment.html>