Open Stack

Hi

On 22 January 2014 21:33, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> I think we're pretty far off in a tangent though. My main point was, if
> you can't selectively restart services as needed, I'm not sure how useful
> patching the image really is over a full reboot. It should take on the same
> order of magnitude service unavailability I think.


The in-place upgrade (currently known as "takeovernode") is not yet well
designed and while there is a script in tripleo-incubator called
takeovernode, nobody is likely to resume working on it until a little later
in our roadmap. The crude hack we have atm does no detection of services
that need to be restarted, but that is not intended to suggest that we
don't care about such a feature :)

I think Clint has covered pretty much all the bases here, but I would
re-iterate that in no way do we think the kind of upgrade we're working on
at the moment (i.e. a nova rebuild driven instance reboot) is the only one
that should exist. We know that in-place upgrades need to happen for
tripleo's full story to be taken seriously, and we will get to it. If folk
have suggestions for behaviours/techniques/tools, those would be great to
capture, probably in https://etherpad.openstack.org/p/tripleo-image-updates
. http://manpages.ubuntu.com/manpages/oneiric/man1/checkrestart.1.html is
one such tool that we turned up in earlier research about how to detect
services that need to be restarted after an upgrade. It's not a complete
solution on its own, but it gets us some of the way.

(Also, just because we favour low-entropy golden images for all software
changes, doesn't mean that any given user can't choose to roll out an
upgrade to some piece(s) of software via any other mechanism they choose,
if that is what they feel is right for their operation. A combination of
the two strategies is entirely possible).

-- 
Cheers,

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/7c2cc801/attachment.html>