 Why don't we go ahead and get started? We had a few technical difficulties that we've managed to work our way through. So we're here to go ahead and provide an update on the Community Generated Roadmap. My name is Carol Barrett. I'm with Intel and part of the product working group. With me today is Ann. Hugh Bliming from Rockspace. So the three of us will go ahead and work together to talk about the content for today. So this content was developed by a team of 16 people that were working from the product work group. They represent companies across our community and across the different industries that we serve, working together with different projects to gather information and synthesize it, and then create the information that we're going to share with you today. The process that we use for creating the roadmap starts with looking at what projects to include. We look at the information that we gather from the user survey on what projects are being adopted by operators in their deployments today as one indicator of what projects to include. We look for things that have 10% adoption and above. Then we also include projects that are sort of essential to an open stack deployment, things like Oslo and Revstack, but wouldn't show up in the user survey. And then the third thing we consider is what are the projects that might be new to open stack or we're seeing rapid adoption and a change in the interest level in the community or in operators or prospective operators to go ahead and guide which projects we include inside the roadmap. As you will see, we're including 28 projects in this version of the roadmap. We start by looking at the baseline of information from the previous roadmap. Then we do some data mining around mid-cycle ether pads and specs and other repos to gather information to create a baseline that we sit down with the PTLs for the different projects and actually have an interview, a structured conversation to understand from them what's accurate in what we data-mind, what additional insights and things they know about that we wanna add onto it. We take all of that and go off and do a little work on it and then bring it back to the project team for them to review it and help make sure that it's as accurate and as comprehensive as we can make it. As I said, in this project, in this release, we're covering 28 projects. That's up from 22 in the last release we did and 17 from the first time that we did this in Vancouver. So we're seeing a steady growth in the breadth of the projects that we're able to communicate the future releases around. And we're also seeing that the project teams are also talking more, talking earlier about what they're gonna do later. So in all and all, we're getting better as a community about projecting where it is that we're going to go. When we compile the information, we organize it around themes. In the last release, yeah, so now we'll keep everybody guessing what the themes are, oh, that's lovely. Do I get help on that? No, Big Ten is bigger than that. So currently we do not cover all of the projects that are in Big Ten. Yeah, so I'll just keep going while we work on that. So for this release cycle, there are five themes that you will see around the groupings for the capabilities. That's adding one new theme from the last release that we did. So the first theme is around scalability. And it's everything that you would expect that to be. It's around how broadly and how many, well, how broadly you can scale a service and performance at that scale as well. The next one is around resiliency, which I think is another term for high availability. The next one after that is manageability. This has a couple of components from user experience as well as ease of operations. The next theme is around modularity. And that has to do with how we refactor projects to enable them to be more easy or extensible. The example I use for this one is Horizon invested a lot of time in building a plugin architecture. So as new projects come into the Big Ten, they can write a plugin for Horizon that allows their information to be exposed to the operators through the common dashboard. And then the theme that we added in this cycle was interoperability. And there's multiple flavors of interoperability from federation to the interoperability across clouds to interoperability and dependencies across projects to backward compatibility of projects as well. So you'll see these themes used throughout the different views that we organized the roadmap in. There was a session yesterday that was held by a couple of the folks in the team to get feedback on the themes. Are these themes helpful? Are they the right granularity? Or would it help people and be more valuable if we added more themes or if we redefined and subdivided some of these themes? So we'll have a conversation later this week when we have our workgroup meeting on Friday. Get the results from that. So you can expect that we'll continue to evolve the information that we put in the roadmaps and how it's organized as we move forward. Okay, yes, Evan. Great, thank you. So rarely is a conversation about roadmaps completed without some type of a disclaimer. In this case, we wanted to go ahead and just give a baseline of the information that you're gonna see is based upon conversations that we had in March with the PTLs. So it was as Mitaka was getting frozen and getting ready to release, but well before the design summit conversations happening this week. So we're using best information to date. You can expect that there will be variations as Newton comes out and as Okada comes out and that's why we do regular updates every quarter on the roadmap. So with that, I'm gonna go ahead and turn over the conversation to Nate to go ahead and talk to you more about the details of the anatomy of the roadmap. Okay. Thanks Carol and Carol. Thanks for getting through that with all the technical difficulties with all such ease and poise. All right, so today I'm gonna take you through the different views that we have that make up the roadmap. Specifically, we've got everything from the 100,000 foot view all the way down to 100 foot view. So if you think of it as elevation, very macro at the bottom, all the way up in space, looking at the planet of OpenStack. So let's go ahead and get started. If we look at the 100,000 foot view, I like to call this one the spider view. This is an aggregate view of all the different projects and which themes that they say they're investing in across the next three releases. So Mataka looking with a real rich set of data that we gather from the PTLs, as well as Newton and Akata looking at more forward looking statements in those PTL interviews that we go through with all of the 28 different projects. So it's kind of weighted and you can see here looking at Newton, you can see how resiliency is slightly reduced, interoperability starts to move forward, and interoperability actually includes things like backwards compatibility as well as cross project compatibility. So looking at things like ironic plus cinder for bare metal volume support, for instance, would be a good example of that. Looking into Akata, that obviously has the most potential for change in terms of the two releases forward. So we use the data that the PTLs are indicating. For that, you can see how scale increases slightly, as well as modularity increases. There's been a lot of focus from the PTLs and wanting to take their code base and make it more modular. It always seems to be more of a forward looking statement versus a statement we're working on right now. So if we continue to zoom in and we look at the 10,000 foot view, you end up with this wonderful eye chart. And so what can you really gleam from this? You need to look in specific places, and so we've actually done a little work to help you out. If you look at the gold rows that are highlighted, you can see those are specific projects that are focusing on a theme across all three releases. So this is an area of focus for them, an area of investment, and one that's a long-term investment. So some of them that we might wanna call out would be heat and scalability, and cinder for resiliency, looking at some of the things like active-active on the cinder side, and then on heat with scalability, some of the parallel provisioning work that they're doing long-term. If you look at the columns, you can see in blue, let me make sure it actually looks that color on this screen. Yes, they are right, very good. You can see for a specific theme, in Mataka, resiliency is one that is focused on, I guess we'll call it number two. If we take out the large box of manageability in the middle, which always continues to be the focus, you can see that resiliency is next in terms of where the most projects are investing time and energy within a specific release, in this case, Mataka. But it's just an example, you can kind of go through and glean things for yourself here. Again, it's a really rich data set. We provide different views and some helpful hints like this so you can help glean things out, but by all means, we want you to educate you today so that you can see these different views and you can go into the data and look at the things that you're most interested in. Most people are interested in two or three specific projects. You can see the big box of manageability there. I guess I circled this because it probably tells me that we're not granular enough and we call a lot of things manageability. So in the future, when we look at how do we evolve our themes for the roadmap, trying to get to a more granular level with manageability so that there's more data that we can mine and that we can categorize. If we continue to zoom down into the thousand foot view, this is a release centric view. And because of the level of detail, we start getting down to putting a subset of projects on each slide. So the thousand foot view is actually made up of eight slides and I'm only gonna take you through two, just to give you some examples of the types of things that you can glean from the view as well as I guess how to read it. So you can see the Mataka, Newton, and Ocata on the Rose. Here you wanna focus on one specific project. So if I take Glantz, for instance, under resiliency, just as Keystone trusts. So we've got more level of detail here, but it's still titles. You're gonna have to drill down into that hundred foot macro view within a project to really get a lot of the data points. And even then you're gonna get links to blueprints and specs and a lot of the details for you to continue drilling down into that data set. But the Keystone trusts, for example, it provides larger image uploads that previously failed due to tokens expiring. So that's certainly an important piece there. If you look at Glantz, again, we continue just to focus on just one project at a time going down into Newton. You can see hardening security for their new V2 APIs, as well as wanting to get V1 APIs deprecated, something that they're gonna be talking about at length with the Nova team here this week in the design summit. So looking at just another example, this one has neutron, cinder, and heat. If you look at heat for a minute, you can see that under scalability, there is heat in the convergence phase one from Ataka, additional convergence engine work for Newton, and final engine parallelization in Okada. And you might say, what exactly is that? That's really the scaled out parallel provisioning work that the heat project wants to do in terms of being able to support higher scale and multiple concurrent workload provisions. And as you can see, I referenced that because it really goes back to the 10,000 foot view and those gold rows that I had showed you that said, where is the project continuing to invest long term in one specific theme? So that takes us to zooming in even further down into the 100 foot view and I'll turn it over to Hugh from RaxBest to take us through a couple of those. Thanks, Nate, and thank you for bearing with us with our projector problems earlier. I think we may have hit peak projector compatibility some years ago, actually. So as my colleagues have pointed out, we've been progressively getting into more and more detail with each of these slides as we go. The thing we should point out is we're not actually expecting you to take all this in right now. In the final slide, we actually have a URL which will take you through to a PDF of all this so you can study it in detail at your own pace. So to use Nova as an example, I did three of the PTL interviews, spoke to Nova, to Neutron, and to the docs team just to find out where they were at, so just quickly walk you through those. These slides have a consistent theme. On the left, the description of the project, Nova, obviously, is a compute service and then on the right, we provide a bit of detail about the specifics of it. So in the case of Mataka, for example, 82 specs were involved in the Mataka project, Mataka release, I should say, and 63 blueprints. For most of these 100-foot views as you go through, you'll see there's actually a link to the video or phone interview that we did with the PTLs in each case. In Mataka, the focus here was on migration, for example, simplifying rolling updates and improving the API documentation. We'll start to see a theme of these in the case of Nova where in Newton, continuing to focus on stability, further documentation changes, and then some internal, I guess, one of a better way to put it under the hood changes around scheduler improvements underneath and implementing support for cells V2. Also, better interoperability with Neutron. Then we look at Okada, this is of course a much more forward-looking view at this point, and the feedback we had from John Garbert who was the PTL, the expectation, is they're pretty much going to do a little bit of everything. So across those themes we spoke about earlier on in the presentation, they'll be looking at all of those. Ironic, which is the bare-metal provisioning engine for OpenStack, should have pointed out that we provide some basic stats around the number of individual contributors, 121 for the Mataka release in this case, and the number of companies that are represented in that process. I shan't insult your intelligence by reading, also rereading what's on the right, but again you can see that same sort of flow of the different emphasis they have on the themes for all of the projects and the underlying work they're doing. And last but not least, another example of 100 foot view for the documentation, project very, very important part of OpenStack being a ultimately developer-oriented project in so many ways. The Taka design series looked at, they started the process of migrating from DocBook XML to RST, and as you can see there, at Mataka it was almost completed, and in Newton that transition has been complete, so you can start to get a sense of the forward progress on all these projects. And then for Okada, the emphasis is perhaps more of an internal one for the documentation team in that making it more efficient, for making their own workflows more efficient within the documentation team, but also making it easier for the various projects involved in OpenStack to contribute to that, to the documentation project directly. I have the pleasure of saying a few thanks on behalf of the team, obviously my co-presenters, but also to the broader product working group and the PTLs who were very generous actually with their time in working with us and responding to our queries about the different directions they had. The URL there is perhaps the key takeaway beyond the presentation itself, if you go to the www.openstack.org slash roadmap, about halfway down the page, the section you're looking for is community roadmap, and you'll actually be able to download the full PDF of this presentation with, I think, of the order of 80 odd pages of information, sort of the 10,000, 1,100 feet views for each of the different projects, and the iChat will be rather easier, I suspect, to see on your own screen than perhaps it was on the project. The project working group is a relatively new group for OpenStack, and we've still very much, welcome people contributing and being involved, and particularly giving feedback as to whether the work or undertaking is useful. There's a session tomorrow afternoon to where we'll be looking at both the user stories and also the development of the roadmap that we do, and of course, the OpenStack Foundation itself has an excellent YouTube channel where you can find out more sort of information. Now, I'm not sure how we're going for time to field questions we have, so if there's any questions from audience, I'd ask merely that we use the microphone over on the left here, because I believe that my stage left you all right. If you have any questions, please walk up to the microphone just for the benefit of the recording, and we'll go from there. Anyone like to step up? It's that time of the afternoon, we're all falling asleep, wondering why this guy has a funny accent. No, no questions? Right, well, again, thank you for your time and your attention this afternoon, and we'll enjoy the rest of the summit. Thank you.