[openstack-dev] [Keystone] Alembic support
Adam Young
ayoung at redhat.com
Fri Jul 26 02:35:36 UTC 2013
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.
More information about the OpenStack-dev
mailing list