Open Stack

On 05/01/2013 02:47 PM, Sean Dague wrote:
> 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).

I think this is the key point here.  Right now as a project we are only
supporting N-1 to N upgrades.  Supporting more than that will take more
consideration than just how we handle db migrations.  It also impacts
the deprecation cycle (as pointed out below), what we need to be
testing, how long we maintain internal API compatibility with rpc, the
range of schema differences our code needs to be able to handle once we
get to rolling upgrades, and more, I'm sure.

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

The ship has long since sailed on the Essex -> Grizzly question, so
there's not much use in debating that at this point.  We can discuss
increasing the support for the future, but right now I'm generally
against it.

OpenStack is still relatively young and is still moving very fast.  I
think we're still a ways off before we want to start increasing how long
we are supporting things upstream.

-- 
Russell Bryant