Open Stack

On Thu, 2015-06-25 at 12:01 -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?


Exactly. Step at a time. It is really just a mechanism to deploy
package based upgrades via Heat... which certainly doesn't solve all of
the upgrade issues (or maybe even the complicated ones) but it is a
step forwards. And it is cool to be able to do all of this with just
Heat.

I would say the jury is still out on how we tackle some of the workflow
issues around full version (major) upgrades while also ensuring minimal
downtime.

Dan (dprince)

> 
> Thanks!
> 
> --Dan
> 
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev