Hi On 22 January 2014 21:33, Fox, Kevin M <kevin....@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
