Open Stack

On Thu, Jun 25, 2015 at 12:01:45PM -0700, Dan Smith wrote:
> Hi Dan,
> 
> > I put together a quick etherpad to help outline the remaining patches
> > left to support package based upgrades within the TripleO heat
> > templates:
> > 
> > https://etherpad.openstack.org/p/tripleo-package-upgrades
> > 
> > The etherpad includes a brief overview of the upgrade approach, a list
> > of patches related to upgrades, and then instructions on how you can go
> > about testing upgrades with devtest today.
> 
> From the looks of this, this is mostly about how you deploy new
> overcloud packages and kick services to start using them, in a sort of
> "stop the cloud, upgrade everything, start the cloud again" sort of way.
> Is that right? Maybe I'm missing some high-level magic that is happening
> in the heat templates?
> 
> Nova has been doing a lot of work to avoid the first step of "stop the
> (whole) cloud", and the inertia seems to be spreading to other projects.
> What you describe in the etherpad seems very puppet-focused, which seems
> (to me) to be a little too naive to orchestrate a rolling upgrade
> operation where things have to happen in a specific order, but where you
> don't have to fully turn anything off in the process.
> 
> Is this evaluation correct? If so, is this the first phase of an upgrade
> approach, or the only goal for the moment? Any thoughts on how we can
> get to something more flexible?

Yeah I think it's fair to say this is just the first step of probably
several iterations towards fully orchestrated upgrades such as you
describe, atm really it's just a way of pushing out minor updates not
version-to-version upgrades (yet).

While puppet is mentioned that's really an implementation detail (the
TripleO heat templates are designed to provide abstractions which enable
multiple implementations, it just so happens that the majority of folks are
working on the puppet one right now..)

You're right to point out how much work is still to be done, both in the
services themselves (to tolerate unexpected restart and DB/RPC version
mismatches), and in defining/automating the workflow which drives the
upgrade.

There are a few ways to achieve the rolling update you refer to, and work
is going on in both heat and tripleo-common which will help enable this in
future.

Steve