 Hi, welcome to Superior TV. Can you please tell us a little bit about yourself? Yeah, I'm Kenny Johnson. I'm the Alliance Manager for Rock Space's relationship with Intel called OSIC. And I'm Rocky Grober, also known as Rachelle Grober. I am a senior cloud technologist for Huawei. Well, thank you for joining us. So today we'll be discussing rolling upgrades. And so I guess the first question that's probably on everyone's mind is, what's new with rolling upgrades in OpenStack? Yeah, so in the Mintaka release, a number of new projects are in the process of applying for the rolling upgrades tag, which is essentially a way of doing interest service upgrade without it requiring the whole service to be pulled down and a database migration to happen and brought back up. So some of those projects are, for example, Cinder and Solometer, I think, are new. And they're in addition to Swift and Nova, which have had the tag in the past. Now, one of the questions I would ask is, they're all these projects and they operate in different modes. Is there a standard place to go to find out, besides the tag, how to actually make them work properly in your environment? Yeah, so there are things like the release notes have upgrade notes nowadays that include the specific instructions that you should take for upgrading a given service. And in addition, you know, the tag is sometimes hard to find, but I would just mention that the tag is available in the Project Navigator on OpenStack.org, which can give you a list of which projects are capable of performing these interest service rolling upgrades. Wonderful. So what are some of the biggest challenges right now with rolling upgrades? So I would say, you know, I kind of view the struggle that many operators have with rolling upgrades is a real threat to the innovation platform that is OpenStack. You know, part of the value of OpenStack is that it's constantly evolving and there's new innovation being added to it every release. And when people struggle with upgrading, it causes a lag and people not to get to take advantage of that. It also hurts our feedback cycle. You know, one of the graphics of OpenStack is that we have users and operators or developers in the community and operators really working closely together. And then when you have operators who are many releases behind because of the pains of upgrading, it's really hard for that feedback cycle to really take effect. So we've been working to improve rolling upgrades with that really kind of specific, it's a really big component that will help improve the adoption of OpenStack. So I want to come back to what we really mean by rolling upgrade intra-project. And what does that really mean for the operators? That means that you don't have to shut down the entire service and do you have co-resident multiple versions or how does that work? It's important to know rolling upgrades can mean a lot of different things. We're talking about intra-service, so within a given service. The typical anecdote that you would hear in the past was that for operators who had deployed Nova, when they were upgrading Nova, they would have to do things like bring down all the Nova services, perform a potentially very long database migration, which could in some cases last not just hours but days, and then bring all those services back up in a specific order at the new version. So intra-service rolling upgrades means that just like you said Rocky, as you upgrade you can upgrade specific subservices of a project or module. There's a sequence that's kind of given to perform this, but it allows the different versions of the same service to talk to each other. So a lot of it has to do with interoperability. Some projects have also added a component of what we call online schema migration or online database migration so that it's not an expensive one-time database migration for your existing data to upgrade to a new version and that it can happen over the course of actually your deployment time in a given version. So that indeed sounds like a lot of progress, so congratulations on making a lot of improvements in rolling upgrades. You mentioned continued improvement going forward, so what's next? So I think that there are still a number of projects that do not support rolling upgrades. Critical ones like Neutron I know are working on it in this cycle as well as I think Cinder will receive the tag this cycle. We're expecting work in Glance and some other of the core projects to complete this cycle so that we can say at least amongst most of the core projects we can do intra-service rolling upgrades. I think there are lots of this continued room for how we orchestrate upgrades so that you don't necessarily have to go through every single one of the release notes and follow those prescriptions exactly, that there are some of the deployment and lifecycle management projects take advantage of what's been done in rolling upgrades and make that more seamless for operators. So I think I will point out that in the recent user survey we've started to see a definite trend towards users and operators deploying or running more recent versions. In the past we seem to see a multiple release delay and now we're starting to see people be closer and closer to the current stable release which is great and shows that the work we've been doing, the whole community has been doing around rolling upgrades has been really beneficial. Now I have one more question. Operators, we've covered how they actually will be affected by this. What will the operators be able to tell their users how this might improve the end user experience? Yeah, I mean from a very practical perspective, it means that as an operator I don't have to tell my end users that their infrastructure platform will be down for hours or days that hopefully their control playing can be always available. It certainly is more available with services like rolling upgrades. In addition, because the operators have to experience less pain to upgrade it means that they're deploying and providing their users with the newest features of OpenStack more quickly which like I said is part of that innovation engine that they get the advantage of all the work that the community does on a regular basis in their actual operational cloud quicker. That's great. So one last question. Is rolling upgrades purely a software solution? Is there only software changes that are needed to achieve rolling upgrades? As an operator you always have to do things like roll in new hardware, fix broken hardware and plan for changes within your hardware architecture. And so rolling upgrades also provides a way to in some ways mitigate some of the pains with that. But there are hardware upgrades. The classic one that both users and operators see is if there is a host that has a problem and that requires that the instances that the user owns and sees have to be migrated off which would involve live migration. Another topic that folks are really big on but not covered here and then once the instances are off the operator can actually bring up the take down the host and fix it and then bring it back up and the whole upgrade process makes it a lot easier to make sure that it's still in line with everything else. And then it can be used again for instances. Great. Well, thank you for bringing us up to speed on rolling upgrades and have a great summit. Thanks, Ram. Thanks, Rocky. Thanks.