Open Stack

I think a new release should contains details of how to do the upgrade
(rather than discovering as we try it)

I should aim that the deliverables for each of the projects in a new version
includes in the release notes:

A. dependencies (i.e. does glance folsom need to talk to horizon folsom or
can it also talk to horizon essex)
B. migration steps to move an instance to the latest version (i.e. how do I
get glance essex to glance horizon) 

Planning an production upgrade will be very time consuming if it requires
the person(s) to understand all the components in depth and derive the steps
from the bug fixes.

One of the items to review within the user/project feedback loop would be
how we validate for a release (I used to call this system test as opposed to
integration test, years ago). This would be the steps where we validate that
a release complies with a set of deployability criteria (such as migration
steps and documentation).

Would the upcoming Folsom release meet these criteria (A./B.) for each core
project ?

Tim

> It would be fascinating (for me at least :)) to know the upgrade process
you
> use - how many stages you use, do you have multiple regions and use
> one/some as canaries? Does the downtime required to do an upgrade affect
> you? Do you run skewed versions (e.g. folsom nova, essex glance) or do you
> do lock-step upgrades of all the components?
> 
> For Launchpad we've been moving more and more to a model of permitting
> temporary skew so that we can do rolling upgrades of the component
> services. That seems in-principle doable here - and could make it easier
to
> smoothly transition between versions, at the cost of a
> (small) amount of attention to detail while writing changes to the various
apis.
> 
> -Rob
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5201 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120829/b7b8ad67/attachment.bin>