Open Stack

Hello guys,

As for TripleO+Upgrades, Kolla is one of ways to help with that. Keep in mind that package upgrades also means dependency upgrades, and that can break things unless we upgrade whole stack at once. No downtime upgrades will basically mean that we need to decouple upgrade process to several steps to ensure per node (and maybe later, with Kolla per service/per node) upgrades. I think we could achieve that with some clever dependency tinkering in heat (start upgrading resource X only if resource Y is already upgraded), or clever usage of breakpoints? Maybe to introduce something like "inprog quota on resource group" -> during upgrade only 1 of 5 resources in group can be played with, after it's finish this lock is lifted and next resource can start upgrade? I think lock like this might make sense for other stacks as well, if we want to minimize impact of stack upgrade. Thoughts?

Regards,
Michał

> -----Original Message-----
> From: Dan Prince [mailto:dprince at redhat.com]
> Sent: Friday, June 26, 2015 12:11 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [TripleO] package based overcloud upgrades
> 
> 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
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev