Open Stack

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?

Thanks!

--Dan