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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
