<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/26/2013 01:55 PM, Doug Hellmann
wrote:<br>
</div>
<blockquote
cite="mid:CADb+p3SEWCKehNrR2Oi7ypNyP_Rx7eXbrL1_8omsK0vjLM4tag@mail.gmail.com"
type="cite">
<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.<br>
</div>
</div>
</blockquote>
<br>
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. <br>
<blockquote
cite="mid:CADb+p3SEWCKehNrR2Oi7ypNyP_Rx7eXbrL1_8omsK0vjLM4tag@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<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
moz-do-not-send="true"
href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc 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 class="h5"><br>
<br>
<div class="gmail_quote">On Thu, Jul 25, 2013 at
10:41 PM, Morgan Fainberg <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:m@metacloud.com"
target="_blank">m@metacloud.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0
0 0 .8ex;border-left:1px #ccc
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
moz-do-not-send="true"
href="mailto:ayoung@redhat.com"
target="_blank">ayoung@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
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>
+-----------------+--------------+------+-----+---------+-------+<br>
| Field | Type |
Null | Key | Default | Extra |<br>
+-----------------+--------------+------+-----+---------+-------+<br>
| repository_id | varchar(250) |
NO | PRI | NULL | |<br>
| repository_path | text |
YES | | NULL | |<br>
| version | int(11) |
YES | | NULL | |<br>
+-----------------+--------------+------+-----+---------+-------+<br>
<br>
<br>
Right now we only have one row in
there:<br>
<br>
keystone |
/opt/stack/keystone/keystone/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>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 class="HOEnZb"><font color="#888888">-- <br>
<div><br>
</div>
-Dolph
</font></span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>