[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