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: [email protected]?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
