Open Stack

I guess it is related to this:
https://review.openstack.org/#/c/6847/

Maybe per-release compaction would be better, but that doesn't help
those deploying close to trunk, and makes it tricker with stable
banches (but I think we leave a few numbers for that kind of thing).

What is the plan now we are in H? Compact all the G migrations into a
single set?

John

On 1 May 2013 18:48, Ryan Lane <rlane at wikimedia.org> wrote:
> On Wed, May 1, 2013 at 8:29 AM, Thomas Goirand <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.
>
> - Ryan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>