 Hello, so welcome to this video about OpenStack NOVA. I'm John Garbert. I'm the current NOVA-PTL, the PTL for the Liberty Release. So we're going to start by talking about what's happened in Kilo. You're OK to advance the slide for me there. Thanks. So the OpenStack NOVA project is sometimes called the Compute Project, and it's focused on providing compute resources to users. I'm not going to go too deep into that right now. There's some great presentations about exactly what NOVA is and how it works. What I'm going to just give some context on is what happened in our last release, the Kilo release. So something new we did in Kilo was to sit down at the summit with all the developers, all the different stakeholders, lots of folks, and get together and work out what are the key things that are a priority for NOVA over the Kilo release. And out of that, the sort of common themes that are coming out is we know NOVA's got quite big. We know that some of the components are starting to get too tightly coupled, mostly due to the fact we've got quite loose interfaces within the components. There's a lot of work going on to fix that. And so we decided to come up with a list of key priorities, most of which are basically different parts in this architectural evolution of NOVA as we're moving forward. A lot of it comes down to creating lots of problems for our users. So there's some bugs that are due to the way things are put together. And also, there's a lot of technical depth slowing down development, making it harder to get features out and all that kind of thing. So we decided to focus on this architectural evolution. Some parts of that include work on improving the NOVA schedule interface. You've got this longstanding feature request that we need to be able to schedule things between projects. So if your cylinder volumes are close to your NOVA virtual machines or compute instances, we need to be able to deal with that. So a lot of the work is building up to getting to that position. Another big thing that we're working on right now is the next version of cells, cells V2. The cells system was originally designed to help the scale out NOVA, but it's actually turned out to be more useful, in fact, for when you've got a deployment, being able to expand the deployment in a nicely controlled fashion. And the original version of cells is very off on one side in NOVA, and we're trying to work hard to make sure that cells is a mainstream component of NOVA that everyone uses by default. So there's an awful lot of work going on behind the scenes to make all that happen. And those are the key parts that got kicked off in Kilo. Now, another priority for NOVA in Kilo is the API V2.1. We need to find a way in which we can evolve our API that really makes the API good and discoverable for our users, but also it's easier for the developers to evolve and to stop there being a friction between these two things. And after an awful lot of work, an awful lot of hard work, we've come up with this idea of microversions and V2.1. From a user perspective, the key thing is that we're having a way to move forward in a way that you can detect if the system has a new API. You can also isolate yourself from changes by requesting a specific version. So if you can request that specific version, you keep on a stable version while the system evolves. And this is happening with people deploying from trunk, people deploying stable releases, and all these different things. But we still want the users to be able to discover exactly what the API is. So there's an awful lot of detailed work there. Probably the key takeaway is to plan us to not break anything. So your existing API requests to V2 will be maintained and it'll work just like they are today. And as you request specific new versions, you'll get specific new functionality as those things turn on. And in Kilo, it was the first release of this. So this is now ready for people to start using. Another thing that came out of the priority that we agreed is an awful lot of work on improving our upgrade. Deployers and users of OpenStack Nova have been asking for some time for a lot of work on upgrade. And this work has been many years in the making. There's a nice blog here describing basically how you can deploy OpenStack Nova and see the, so you start with the Juno version. You've got that all working. And there's a way to have very minimal downtime when you move into the Kilo version. Now, there's still a slight amount of API downtime with the current approach, but as you'll see, we're sort of building on where we're getting to. We've got to a very nice smooth upgrade process. There's all the existing things that we have done for some time now in Nova with upgrades. We ensure that we don't pull features away without warning people as deprecation windows. We was trying to find some smooth transition to the new thing, if there's a new thing and placing an old thing. But all that existing work's still happening, but trying to make the upgrade as smooth as possible. There are loads of other things going on in Kilo. The best thing is to reach out and find out what's happening. You can look in Launchpad to see the blueprints and the bugs that were particularly fixed. And there's really some more in-depth presentation on the specifics of each of those features, but this is kind of just an overall flavor of what's happening in Kilo. Excellent, so we'll move on to this slide that's now going to be talking about the plans we have for the current release, Liberty. The first thing here is I'll refer to the presentation that Thierry did on the release management. We're now focusing much more on reporting than prediction. As such, I'm kind of just saying these are the plans we have. It's quite hard to actually predict exactly when things will land, but right now these are the kind of things that we have in flight for the Liberty release. So the first piece is we went through the process of prioritization again, and most of the key things that came out of that were the architectural evolution that we're currently working on. The first part of that is we've now got V2.1 released, but now we need to take the next steps. The first part is that we actually need to get rid of the old code. We currently have parallel implementations, so we need to make sure that the V2 support is as good as we can possibly make it and start to get adoption of that V2 support in production environments so that we can deprecate the old V2 code so that we have a single code base serving both the V2 API, the V1.1 API, which is just an alias, and the V2.1 API. Right now we're at the case where the tempest tests work on for both V2 and V2.1 requests is the same tests against both code bases, so we know it's good to that level. We're just trying to get it to the next level when we're talking about relaxing validation appropriately and all that kind of thing. There's a key part of this effort is to make sure that we go back and get the docs to a good position so it's nice and usable. We're working hard to get Python over client support V2.1 well so that we've got the good foundations to build on as we add features into the API. Lots of the focus you'll see going forward with the API is to ensure that you have a good interoperable API. The Dev Core work is starting to focus the community's minds on exactly where we have issues. One of the first things we're doing with the V2.1 API is to try and drop this idea of extensions so the API is the full API. This then has the knock-on effect so the only way you can turn off bits of the API are through policy changes. So we're looking at how we configure policy within the API so we get that. Working well and really usable and we'll be good at cross upgrades because there's a good bit of rework happening there. The next key part that we're doing during Liberty is more work on upgrades. We want to get to that zero downtime upgrade. Now just to step back for a moment, when we upgrade Nova, there is no VM downtime, there's no VM connectivity downtime. We're talking about the control plane here so the API availability and the ability for the API to serve the request that it's given. So in the Kila release, we were able to do, for the first time, we were able to do the database migrations completely online. So in the past, you had to wait an awful long time to be able to, in certain cases where you have a big database, you had to wait a long time for the migrations so that was a key pain point. With the Kila release, we've moved to ensure that all data migrations are moving data from one row to another, one table to another. They all happen online so there's no need to wait for that to happen. The flavor migration is the first example of that and in the, in the Liberty release, we're planning to take it a step further to make sure that all schema migrations are like strictly in an expanded contract phase. So we've recently merged the experimental version of this where we can split the deep integration into the bit that you do. Before you upgrade the services and the bit you do after everything's running new code. It so happens that when moving to Juno to Kila, we'd only done expansions so that's how we were able to do the online migration from Juno to Kila. In Liberty, we're trying to take that a step further. Cell V2 is progressing. The plan for Liberty is to try and get to the point where by default all the deployment starts with using cells V2. Just like caveat to that is that you can only have a single cell V2 cell right now. The plan is that in the M release, we'll look at having multiple cells and being able to convert cells V1 uses the cells V2 and all those kind of slightly more complex issues we're waiting, we're leaving for M. That's the plan for Liberty is to get everyone using cells V2 as a good separation between the API and the compute layer. There are generally lots of this work is, as I was saying before, is all focusing on making sure that we work hard at fixing fundamental issues that are creating bugs and ensuring that we increase the development of velocity and we're able to keep delivering great features for our users. There's so much more in review and so much more that's currently on the planning. There's some links here to give like some flavor what's currently being proposed and planned for the Liberty release, but hopefully a lot more on that once we have some more concrete things to talk about. So now I'm going to move on to my next slide, which is about scaling out the Nova community. We're always evolving as a community, the whole open stack community is always evolving, but during the Liberty timeframe, we're trying to have a much more focused effort looking at what we're doing and how we operate as a community and how we can improve to scale out what we're doing. Having had lots of conversations, different people on all sides of the story, the key thing we're trying to work on right now is better communication. So we're trying to talk about writing down what our plans are and probably much more importantly, make a really big effort describing why we're doing what we're doing. We want it to be really easy for people to engage with debates on our design, on our development process, on everything. And part of that is to ensure that we clear about the history behind what we're doing and why it is so that we can make sure that people can meet the ground running when they're joining the debates. Part of this, like following on with this, is to make sure that we are really approachable and we make an effort to reach out. So we're doing some key mentoring and some onboarding work to make sure that it's easy for newcomers to understand where to get started, what we're doing, where we need help. When we looked at the priorities for Liberty, we actually have an extra list this time for Liberty saying, hey, these are things that are really important to Nova. We just don't have people working on these right now, but we'd love to have people working on them. So that's a great place to see where can I help in Nova. There's a great list of things for people to step up. And through the mentoring program, we're trying to make sure that we have people available to actually talk to people about these and get things moving forward. I'm hoping to eventually have like a mentoring and a team that's able to be specific people to reach out to right now. It's a case of emailing myself or asking on the mailing list and we'll get people to go and help and discuss things with you. But we're really trying to bootstrap that effort. Part of that is we need to be expanding the Nova core review team. So the Nova core team are specifically locking out for people doing great reviews and encouraging them to do more and to work with them to the point where we can get them added onto Nova core and we can get that team expanding again. So we need to set a context of the work that's happening in Nova. One of the key friction points that we have is that Nova's got to such a large size. It's a big project. It's hard to understand all the areas. We want to make sure that doesn't get any worse. What we're doing to try and help that is we're trying to be very specific about what the project scope of Nova is. I've linked to a document on the slide that that we're trying to, that we're starting to sort of describe exactly what the scope of Nova is. This is not Nova trying to be difficult. It's Nova trying to make sure that the right thing happens for the open stack ecosystem. In the early days, we split out Nova volume because it was clear there was a community of people that cared about volume drivers that should go and live by themselves. And the Cinder project was born. It's a great example of where Nova saying, no, we're not the right project to do this. There's a distinct community voice that needs to have its own project and go and run with this thing. That worked well. Another example is heat. People wanted to add orchestration APIs to Nova because Nova was doing the compute kind of things but heat's actually been in a much better position to go and run with the idea and build up a great ecosystem around that without having to be part of this mass Nova community. They're doing a great job on that. So we're looking for more opportunities to split things out. But we're still looking for innovation on what we're doing. At the core of what we're doing is we've got to get better at it. So for example, there's lots of innovation happening around the schedule and different ideas there. That's great stuff. The schedule being an example of the component we may want to pull out in the future if we can get some solid interfaces around it so that it can live by itself as an independent project. But that's the kind of scope there. We're trying to make sure that we have a clear scope for Nova so that when people come with their ideas they can see if it fits with the Nova scope. So looking at what Nova is concentrating on right now, we need to be clear about what our mission is, what our values are, the current goals that we have. Just to start that conversation, right now it's two clear things are emerging. Firstly, the Nova API is great when it's a great platform for interoperability. It's great when we have a solid ecosystem that builds up around that. That's happening. We need to support that and encourage it and improve it. An example is when you come to add something that's a very specific feature. We need to look at a way in which we can implement that feature so it's more applicable between all the different drivers and all different use cases so that that is something that could be adopted by the full ecosystem. Rather than being an oddball thing on the side that no one can use. So I think that's best for the people adding the features because the features they add will be able to use them in wider audience. And it's the right way we think to go forward. The other thing that was emerging from those discussions is we have a lot of users. Users are relying on Nova to keep working and keep working well for the future. It's a part of that. It's all around ensuring that you have good upgrade which we've talked about a lot. But equally, you've got to be able to scale out that deployment as the needs of those users grow. And you've got to make sure that with all these changes and all these different things that are happening, we still want the stability of the system still needs to work. When we're looking at upgrade, we're actually looking at people deploying from any point on the master branch. So we have people deploying production clouds from taking a point on the master branch and then taking that and doing some stabilization and deploying that. And that's really useful for getting leading-end features and also get all the latest bug fixes. It's doing a great job at that. There's also all the people doing who are taking releases that have stable branches so that they can get non-impacting bug fixes that way. But I hope with all the live upgrade work that you can, like, from commit to commit and release to release, you get this great live upgrade path. The other part of that is that there's lots of conversations right now about how we change the version numbering. The more observant of you will see on the slide on Liberty, it's called the version trial release rather than the 2015.1. It's part of the projects moving towards a more sem-ver-like versioning scheme. But what I wanted to say was that we're still in order to have all this upgrade. The restriction is that you, in order to upgrade from J to L, you have to have first upgrade to K. And that allows us to have all the backwards compatibility code to allow the smooth upgrade. We can have all that code in the code base, but we know that we can get rid of it in a reasonable timeframe. So that's why we're doing that sort of upgrade requirement. So given all the version changes, that's the debate that's worth getting into right now with how upgrade works. Anyway, that's a kind of overview of some of the things we're doing, the scaling with the Nova community. The key thing we're trying to do is go back and describe why we're doing what we're up to and making sure that we describe what we're up to well. So the next slide is actually on the, where we're going next. What are the possible future priorities? The first thing I wanted to mention is some work on what I've been calling feature classification. This is an evolution of our existing hypervisor support matrix and compute driver classification system. For those not aware of that, the basic idea is we want to be very clear to our users what combinations work well, what feature is available in which combinations and overall give clarity on what the upstream community are actually testing and what we know works in each release and each commit to each commit. This is going to help us focus on where we have like feature gaps between the different combinations where bits of the code perhaps not being as tested as well as they should be or getting forgotten and trying to get attention for those. Basically, we're trying to reinvigorate the effort that was started with the compute driver classification. Probably left a little over two years ago. They're trying to re-kick that effort so that we can get going on that. In the Liberty release, we're working to make sure that you have all the fundamentals that we can evolve with the 2.1 API in place. When we get beyond getting that, once you've got that sorted and that's all in place, we really want to look at evolving the API in terms of its interoperability. Like one of the key areas we know we have a weakness is that the discoverability of features that are triggered by image metadata and flavor retrospects is not great. You need a better mechanism to model that. There's still, from a deaf core point of view, there's lots of questions about how you interact with OpenStack and networking and the compute APIs and networking. We need to go back and answer some of those fundamental issues in the life of everything that's happening with the network. Something you've probably picked up here is that a lot of the work is actually pulling out what I like to call like bug themes. When we're talking to our users and seeing the bugs that are coming in, often there's these themes that emerge where you can see an area of code that needs work. We're making sure to identify those and try and get people to work on those. Some of the big things that are coming up right now are quotas, so we have a plan that we're working on for quotas, we need to get some more effort behind that. Another part of the story is looking at all the cross-project interactions. So we're looking carefully at how we integrate with Cinder, how we integrate with Neutron's new sort of driver system and what that means for Nova. So we're looking at all these integration pieces where it's known to be a place where things can fall between the cracks when things go wrong. So making sure that that's solid and we have good ways of recovering from the errors and we understand what's going on. So it's a case of doubling down on those efforts and making sure that we have the best interfaces we can between our projects. I'm looking at how to evolve that. There's a big lot of work there. We're trying to kick that off. There's some work to adopt the brick library that we hope to get into Liberty. Brick being a new interface for connecting certain things to Cinder. We hope to see some great stuff moving forward on that. Going back to these bug themes, one of the big ones that I wanted to pull out by itself on its own not the bullet point here is there's a lot of work and thinking behind how do we get from where we are today to like the next level of reliability and stability and ensuring that the API is very clear at the error reporting and we have a good strategy across the whole of an overcode base. The sort of code name that's been given for this in the past is the tasks effort. Right now we're sort of trying to solidify our ideas on this so that we can get more folks to come and help with sorting this out. It's exciting that we're starting to get some traction on where we'll go forward with this. And this is another thing that's coming out of now we have a good way of evolving the API. How do we move forward in terms of improving the stability feel of the API when you're interacting with it? Well, thank you very much for your time. Thank you for listening. I hope that gives you a good idea of what's happening in the Liberty release, what's happened in Kilo and why we're looking for the future. If you want to reach out to me, feel free. I'm on IRC during UK working hours. I'm my IRC handles John the Tuba Guy. You can reach out to me on Twitter at John the Tuba Guy. Feel free to drop me an email at my usual email address. Thank you very much for your time. I hope that was useful.