[openstack-dev] [TripleO] our update story: can people live with it?

Jay Pipes jaypipes at gmail.com
Wed Jan 22 20:49:52 UTC 2014


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" <clint at fewbar.com>
> > > > To: "openstack-dev" <openstack-dev at 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




More information about the OpenStack-dev mailing list