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
<[email protected] <mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
-Dolph
_______________________________________________
OpenStack-dev mailing list
[email protected]
<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
