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