Open Stack

On Fri, Jul 26, 2013 at 12:55 PM, Doug Hellmann <doug.hellmann at dreamhost.com
> 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.
>

+1; that sounds like it solves the missing piece ayoung was looking for.


>
>
>
> 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
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130726/41e56571/attachment.html>