On Wed, 2014-01-22 at 12:12 -0800, Clint Byrum wrote: > Excerpts from Jay Pipes's message of 2014-01-22 10:53:14 -0800: > > On Wed, 2014-01-22 at 13:15 -0500, Dan Prince wrote: > > > > > > ----- Original Message ----- > > > > From: "Clint Byrum" <cl...@fewbar.com> > > > > To: "openstack-dev" <openstack-dev@lists.openstack.org> > > > > Sent: Wednesday, January 22, 2014 12:45:45 PM > > > > Subject: Re: [openstack-dev] [TripleO] our update story: can people > > > > live with it? > > > > > > > > Given the scenario above, that would be a further optimization. I don't > > > > think it makes sense to specialize for venvs or openstack services > > > > though, so just "ensure the root filesystems match" seems like a > > > > workable, highly efficient system. Note that we've talked about having > > > > highly efficient ways to widely distribute the new images as well. > > > > > > Yes. Optimization! In the big scheme of things I could see 3 approaches > > > being useful: > > > > > > 1) Deploy a full image and reboot if you have a kernel update. (entire > > > image is copied) > > > > > > 2) Deploy a full image if you change a bunch of things and/or you prefer > > > to do that. (entire image is copied) > > > > > > 3) Deploy specific application level updates via packages or tarballs. > > > (only selected applications/packages get deployed) > > > > ++. FWIW, #3 happens a heck of a lot more often than #1 or #2 in CD > > environments, so this level of optimization will be frequently used. > > And, as I've said before, optimizing for frequently-used scenarios is > > worth spending the time on. Optimizing for infrequently-occurring > > things... not so much. :) > > I do understand that little tweaks are more common than whole software > updates. > > I also think that little tweaks must be tested just like big ones. > > So I would argue that it is more important to optimize for trusting that > what you tested is what is in production, and then to address any issues > if that work-flow needs optimization. A system that leaves operators > afraid to do a big update because "it will trigger the bad path" is a > system that doesn't handle big updates well. > > Ideally we'd optimize all 3 in all of the obvious ways before determining > that the "one file" update just isn't fast enough.
Well said. No disagreement from me. Best, -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
