[openstack-dev] Upgrade from Essex to Grizzly has to be supported

Morgan Fainberg m at metacloud.com
Wed May 1 18:37:31 UTC 2013


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).

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.

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).


On Wed, May 1, 2013 at 11:01 AM, Monty Taylor <mordred at inaugust.com> wrote:

>
>
> On 05/01/2013 01:48 PM, Ryan Lane wrote:
> > On Wed, May 1, 2013 at 8:29 AM, Thomas Goirand <zigo at debian.org
> > <mailto:zigo at debian.org>> wrote:
> >
> >     Hi,
> >
> >     It seems that by policy, upgrading directly from Essex to Grizzly
> isn't
> >     supported. There's simply no SQL upgrade scripts for it.
> >
> >     Though, I think this is a huge mistake. Currently, in Debian, we have
> >     Essex in Wheezy and SID, and Grizzly in Experimental. There's no room
> >     for Folsom anymore. I already have some bug reports that it isn't
> >     possible to upgrade from SID to Experimental.
> >
> >     As much as I understand, the only problem is the SQL upgrade scripts.
> >     What would it take to have the Essex to Folsom upgrade scripts
> re-added
> >     to Grizzly? Is this something I will have to maintain myself (which
> >     would be quite annoying), or could the policy change, and the scripts
> >     added upstream?
> >
> >     Thoughts?
> >
> >
> > I don't understand why sql upgrade scripts from any release would ever
> > be removed. It should be possible to do a data migration from any older
> > version of OpenStack to the current version.
>
> I believe we collapse them down on each release, so that grizzly has a
> single migration that knows how to migrate from folsom. I could be wrong
> about that.
>
> If there is a different thing we can do to make some things better here,
> I'm not opposed to that - but I do not believe that we're going to spend
> a good amount of energy on supporting arbitrary version upgrades such as
> essex->grizzly. It's possible that it'll work with a sequence of db
> migrations. Essex isn't supported in any way by OpenStack at the moment,
> so there would be absolutely no way to test that such a thing works.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130501/8c2b6bfe/attachment.html>


More information about the OpenStack-dev mailing list