<div dir="ltr">While I would agree that it would be nice to support Essex to Grizzly upgrade patterns, I can see the difficulty in supporting the SQL Migrate scripts as a lot of the core pieces have changed (logging, config, etc) and with the volume of migrate scripts it is fairly nice to have it collapsed for "new" installs. Having to adjust every SQL Migrate script for the codebase structure changes (when you are in the 100s+) becomes very time consuming and typically will impact a (relatively) smaller subset of users: Essex -> Grizzly is a big jump (and skipping releases is tough to provide direct support). <div>
<br></div><div style>The approach we are taking is to have the migrate repo for Folsom used as part of the deployment process. Migrate with a stub Folsom checkout and then use the actual Folsom -> Grizzly upgrade path.</div>
<div style><br></div><div style>I think that the best plan of action for Essex -> Grizzly is documentation. For the future, this might be something we may want to bring up as a discussion point (maintaining an upgrade pattern for skipping a given release, based upon the compliance requirements for interoperable installations).</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 1, 2013 at 11:01 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
On 05/01/2013 01:48 PM, Ryan Lane wrote:<br>
> On Wed, May 1, 2013 at 8:29 AM, Thomas Goirand <<a href="mailto:zigo@debian.org">zigo@debian.org</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:zigo@debian.org">zigo@debian.org</a>>> wrote:<br>
><br>
> Hi,<br>
><br>
> It seems that by policy, upgrading directly from Essex to Grizzly isn't<br>
> supported. There's simply no SQL upgrade scripts for it.<br>
><br>
> Though, I think this is a huge mistake. Currently, in Debian, we have<br>
> Essex in Wheezy and SID, and Grizzly in Experimental. There's no room<br>
> for Folsom anymore. I already have some bug reports that it isn't<br>
> possible to upgrade from SID to Experimental.<br>
><br>
> As much as I understand, the only problem is the SQL upgrade scripts.<br>
> What would it take to have the Essex to Folsom upgrade scripts re-added<br>
> to Grizzly? Is this something I will have to maintain myself (which<br>
> would be quite annoying), or could the policy change, and the scripts<br>
> added upstream?<br>
><br>
> Thoughts?<br>
><br>
><br>
> I don't understand why sql upgrade scripts from any release would ever<br>
> be removed. It should be possible to do a data migration from any older<br>
> version of OpenStack to the current version.<br>
<br>
</div></div>I believe we collapse them down on each release, so that grizzly has a<br>
single migration that knows how to migrate from folsom. I could be wrong<br>
about that.<br>
<br>
If there is a different thing we can do to make some things better here,<br>
I'm not opposed to that - but I do not believe that we're going to spend<br>
a good amount of energy on supporting arbitrary version upgrades such as<br>
essex->grizzly. It's possible that it'll work with a sequence of db<br>
migrations. Essex isn't supported in any way by OpenStack at the moment,<br>
so there would be absolutely no way to test that such a thing works.<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>