Open Stack

On 05/01/2013 02:37 PM, Morgan Fainberg wrote:
> 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).

Fair, but realize it's not just the db upgrade path (though that's the 
first visible explosion).

To support skip upgrades you need to get all the core teams to commit to 
Deprecate in N, remove in N+2, instead of Deprecate in N, remove in N+1.

It would mean that grizzly would have still shipped with nova-volume. It 
would mean that nova-network would need to still ship in I, as would the 
bare-metal virt driver (just for some examples).

Not to say it's not worth a discussion, but realize that it's more than 
just leaving a few db migrations around.

	-Sean

-- 
Sean Dague
http://dague.net