Open Stack

Sean,

That is a very valid point.  It wouldn't really be a terrible plan to do
the deprecation strategy you described; I totally agree this is far, far
more reaching (and requires buy-in from far more people) than this
discussion has been so far.  Perhaps we should aim to get this on
the docket for the next summit (if there is enough interest via the mailing
list).

--Morgan


On Wed, May 1, 2013 at 11:47 AM, Sean Dague <sean at dague.net> 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).
>
> 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
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/5551529b/attachment.html>