<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Jul 26, 2013 at 12:55 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">It makes sense, though, if the data is going to be (potentially) coming from separate databases. Is that any different for sqlalchemy-migrate?<div>
<br></div><div>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.</div>
</div></blockquote><div><br></div><div>+1; that sounds like it solves the missing piece ayoung was looking for.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div><div><div class="h5"><br>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 26, 2013 at 1:42 PM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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).</div>
<div class="gmail_extra"><div><div><br><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 10:41 PM, Morgan Fainberg <span dir="ltr"><<a href="mailto:m@metacloud.com" target="_blank">m@metacloud.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
+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.<div>
<br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Morgan Fainberg</div><div><div><div><br><div class="gmail_quote">On Thu, Jul 25, 2013 at 7:35 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
In the current Keystone implementation, we have a table like this:<br>
mysql> desc migrate_version;<br>
+-----------------+-----------<u></u>---+------+-----+---------+---<u></u>----+<br>
| Field | Type | Null | Key | Default | Extra |<br>
+-----------------+-----------<u></u>---+------+-----+---------+---<u></u>----+<br>
| repository_id | varchar(250) | NO | PRI | NULL | |<br>
| repository_path | text | YES | | NULL | |<br>
| version | int(11) | YES | | NULL | |<br>
+-----------------+-----------<u></u>---+------+-----+---------+---<u></u>----+<br>
<br>
<br>
Right now we only have one row in there:<br>
<br>
keystone | /opt/stack/keystone/keystone/<u></u>common/sql/migrate_repo | 0<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><br></div>-Dolph
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div></div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>