Open Stack

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.