 Hi, this is Heidi Joy Trethewey with the OpenStack Foundation and the Newton Design series. Today we're talking to Matt about NOVA. Matt, would you introduce yourself a little bit? Hi, my name is Matt Riedemann. I'm a NOVA PTL for the Newton release. I've been working on OpenStack for a little over two years. I've been core on NOVA for about two years. I started working out with packaging it for IBM's distribution. I worked for IBM in their public cloud group and eventually sort of got into, we were running Tempest on our packages and that's how I got into QA and eventually got into NOVA, the broader OpenStack community. Great. Well, tell us more about what NOVA does. It's one of the most adopted projects in OpenStack. It's a core element of OpenStack, but for those who aren't as familiar, tell us what NOVA can do. Sure. So, NOVA is the compute service. Basically, that's where you boot VMs. You can also boot bare metal nodes through the Ironic driver and containers like LXD. There are some other VRT drivers on a GitHub for like Docker and LXD, but they're not part of the actual official NOVA repo. But it also uses Neutron for networking, sender for volume storage, clients for images, keystone for authentication. So it relies on a bunch of the other projects too. Great. And then let's talk about what your team discussed in Austin. What were some of the hot topics that came up in discussions during the design summit? So, the design sessions for NUIN were really building off MATACA and Liberty and just a lot of multi-release efforts. We really had a lot of cross-project sessions in NUIN. I think we had like five sessions with other projects in NUIN. The big ones were probably with Neutron to go over the routing networks, work that Neutron is working on, because that's dependent on some scheduler work that NOVA is doing. And to talk about the get-me-in-network feature that we're working on in NUIN. Neutron landed the API for that in MATACA and NOVA is going to be integrating it in NUIN. Another one was with Glance, because we've been trying to integrate with Glance V2 and in NOVA for a long time, so Glance can drop their V1 API. So we had a session to basically make sure we're all on the same page, because communication is through IRC, it takes a while, and mailing lists and all that, and code reviews and stuff. So it's nice to just get everybody in the room and make sure we're all on the same page before we work on this stuff for months. I guess the other hot topics, I mean the main things were like Sales V2, that's another effort that's been going on for a long time, and the scheduler work that J-Pypes and Pristant and some of the subteam has been working on, which I guess is another nice thing that you can really tell in the Newton design sessions that NOVA is really sort of naturally grown into effective subteams, like there's an API subteam, sales, scheduler, live migration. So we had sessions really around all of these subteams. We had our normal on-conference sessions, which are 10-minute slots for people to just come and talk about whatever blueprint or feature they're trying to get in. And then Friday is all basically just meetup style. It's open to discussing whatever. We also had a session on moaning fruits and getting started in NOVA, because NOVA is a big project, and it's sort of intimidating when you get started on what you should actually work on. And we actually have a lot of sort of mechanical, broad things that people can work on to help clean up and get new, like just get their feet wet really. And this session was really talking about how do we clearly document what these efforts are, who to contact if you're new and you're interested in working on them and trying to do that in a sort of a common way. So that was actually a pretty packed room. There were a lot of new people in there, and the Internet was full of ideas on how to help out there. That's great to hear. So Matt, during, or as you're planning for Newton, what were some of the user needs and problems that bubbled up to the top that your team is trying to solve in the Newton release? So the main user needs are really the things that, as I mentioned, like Sal's B2 and scheduling. These are really like scaling issues, technical debt type problems. So Nova's had Sal's B1 since grizzly, but it's sort of a an additional code pass to all the normal code pass. It's not feature complete as far as the Nova API is concerned. And this is really about getting Sal's B2 to be a native part of anything you do with Nova goes through this Sal's B2 path. And it's about redefining a lot of the data models. And so everything's not just in a single database, but modeled more accurately for how everything works. In Mataka, we've laid a lot of the foundations and designs for how a lot of this is going to work. But didn't get a ton of like actual code merged and reviewed in Mataka. So at Newton, we've actually already made some pretty good progress on migrating a lot of the data, doing online data migration, Sal periods are smooth. And then with the scheduler stuff, this is also a scaling issue because if you're using things like shared storage, we don't actually model that accurately today. So this has been a known like latent bug in Nova for a long time. And it's also something that for like Neutron Rotative Networks, if they're going to need to be able to tell Nova like for IP submit pools that they have a certain allocation of these and then Nova scheduler can use them for putting instances into these things. The other big user stuff that we talked about was really API cleanups. There's two big pushes for this. And even one is pulling all the API documentation entry and actually cleaning it all up, cleaning up all the API extension documentation. So validating that it is correct and complete and actually usable. We've been making, we had a sprint last week to do a lot of the cleanup of this review of it. The other thing for API is putting the policy defaults in the code, sort of like config options. But this is so that instead of a deployer getting a gigantic policy JSON file, it's basically shipped as empty, all the defaults are in code. And then if a deployer wants to override the policy, they just have to do that one, whatever action they need to override at the time. Eventually, this will build into what we would like to have is discoverable policy through the API. So a user can ask Nova, what am I allowed to do basically or what is, what is capable on the cloud that I'm talking to? Because if you're using Litvert KVM or Zen or a different bird driver, you may not be able to do certain things on that cloud. So really as a client, you're only able to handle errors and it's not a great user experience. Well, that's exciting how much work you've already gotten done just a couple weeks after the design summit. What would you say are the top, say three features or enhancements that we can look forward to when the Newton software release comes out in October from Nova? So if you, the documentation for the Nova specs repo actually has all of the priorities listed out in detail. The top three are really cells B2 work, the scheduler work, trying to get the data model in place for all the scheduler stuff doing the online data migrations and eventually having a separate placement API for our end point. So eventually all the scheduler stuff can be split out. But those are the top two, then the API one, the API work for policy defaults and code and the API ref cleanup is also a priority. We have a few other priorities that are documented in the Nova specs repo. But those are the top three. Great. So as you know, the product recruit has a way of uniting all these different projects priorities with a set of themes, those themes being scalability, resiliency, modularity, manageability and interoperability. And I was wondering from this point of view, what are the top few themes that are going to be the most substantially addressed in Newton? So the cells B2 stuff and the scheduler stuff is really, I mean scaling fits into most of those, I think, as far as interoperability, the building up to API discoverability capabilities and stuff like that. That's sort of a stretch that's more of a longer term, probably Okada type item. So what we're working on and Newton is building up to those type of interoperability things that the other thing with the scheduler stuff is we had a pretty fair long discussion about how do you standardize and model post capabilities through the API, which is an interoperability issue. That's what I was talking about with Zen and the different bridge drivers. But we have to sort of lay, we have to clean up some of the existing stuff that we have and model it appropriately before we can even start getting into these other things that are down the road, but really more for Okada. But we have other, as far as like a big thing that's already happened in Newton has really been the backlog that we've been carrying since Otaka Liberty, even in Kilo in some cases. We put a freeze on new specs up until the summit, which before we used to just say once master is open you can propose new specs and we'll approve them. For the first, I don't know, since Newton started until the summit we actually said we weren't approving any new specs. If it was approved from Otaka we would approve it again, but we've really tried to lock down new debt basically that we're taking out and we're trying to get a lot of these long running features actually worked on because a lot of the core team is actually working on a lot of these too. So the core team is reviewing them and working on a lot of them. So we need to get a lot of this backlog cleaned up before we can add new features basically. That's great to hear. Well, is there anything else Matt that you'd like to add? I think that's it. All right, well thank you for taking time to talk to us about what we can look forward to from Nova in the Newton Cycle.