Open Stack

Dan Prince has volunteered for doing that in the past. In nova, with the 
large number of db migrations, not making a fresh install go through 
type conversions back and forth has it's advantages.

The reality is that we only do deprecation for 1 release anyway. So 
while you could take an Essex config -> Folsom and it should work (with 
some ugly errors in the logs), going from Essex -> Grizzly isn't going 
to. I know at least half a dozen ways that's going to break for sure, 
and I'm sure there are plenty more.

That means anyone trying to support Essex -> Grizzly would need a lot of 
their own upgrade scripts anyway.

	-Sean

On 05/01/2013 02:00 PM, John Garbutt wrote:
> 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
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Sean Dague
http://dague.net