[openstack-dev] [TripleO] our update story: can people live with it?
clint at fewbar.com
Fri Jan 24 19:47:23 UTC 2014
Excerpts from Day, Phil's message of 2014-01-24 04:39:10 -0800:
> > On 01/22/2014 12:17 PM, Dan Prince wrote:
> > > I've been thinking a bit more about how TripleO updates are developing
> > specifically with regards to compute nodes. What is commonly called the
> > "update story" I think.
> > >
> > > As I understand it we expect people to actually have to reboot a compute
> > node in the cluster in order to deploy an update. This really worries me
> > because it seems like way overkill for such a simple operation. Lets say all I
> > need to deploy is a simple change to Nova's libvirt driver. And I need to
> > deploy it to *all* my compute instances. Do we really expect people to
> > actually have to reboot every single compute node in their cluster for such a
> > thing. And then do this again and again for each update they deploy?
> > FWIW, I agree that this is going to be considered unacceptable by most
> > people. Hopefully everyone is on the same page with that. It sounds like
> > that's the case so far in this thread, at least...
> > If you have to reboot the compute node, ideally you also have support for
> > live migrating all running VMs on that compute node elsewhere before doing
> > so. That's not something you want to have to do for *every* little change to
> > *every* compute node.
> Yep, my reading is the same as yours Russell, everyone agreed that there needs to be an update that avoids the reboot where possible (other parts of the thread seem to be focused on how much further the update can be optimized).
> What's not clear to me is when the plan is to have that support in TripleO - I tried looking for a matching Blueprint to see if it was targeted for Icehouse but can't match it against the five listed. Perhaps Rob or Clint can clarify ?
> Feels to me that this is a must have before anyone will really be able to use TripleO beyond a PoC for initial deployment.
Right now we are focused on the hard case, updates requiring
reboot. Avoiding the reboot is a bit more than an optimization, but it
is something we will get to once we've nailed the harder case of handling
a new kernel and reboot gracefully.
I for one have a fear that if we start with the easy case, we'll just
avoid the hard one, spend less time on it, and thus do it poorly.
More information about the OpenStack-dev