 All right, she'll be here. Hello. Hi. Good afternoon. And thank you for coming to the Let's Talk Roadmap Open Stack Style session. Today, Carol Barrett from Intel, Mike Cohn from Cisco, and myself, Shamal Thar from IBM, will be representing the product working group to discuss a little bit about what the product working group is, but then also share a community-generated roadmap that we have compiled working group, the project tech team leads, for the various open stack projects. So with that, I would like to pass this off to Carol to explain a little bit about what the product work group is. Thank you, Shamal. So the product work group was formed at a conversation that started in Paris just about a year ago today. And the dialogue sort of went along the lines of the essential capabilities are starting to emerge in the open stack services. And the next level of adoption and value to the enterprises and open stack users is going to be driven by really understanding their requirements and implementing those capabilities across the different projects and the different releases inside of open stack. And with that, the product working group was formed with three main elements to its charter. First one was really about that. How do we increase the voice of the operators, the users, the markets that open stack is targeting deployments? So that we can meet those needs. We can understand them. We can communicate them. We can take action on them. We can implement them, we being the community. The next one was around helping to support and enable cross-project capability development, cross-release implementation of capabilities because these new requirements that we have, they're bigger and they're more system-wide. And that's not something that has been historically undertaken by our community. And it's challenging because our community is big and broad and it's getting wider with an under-big 10 on a regular basis. So how can we go ahead and help that so that we can implement these things and actually get those features out in releases? And then the third one was to go ahead and publish a multi-release roadmap that would take that information and allow us to communicate it out to current operators, new operators, and other folks who are interested in what are the capabilities coming down OpenStack so that somebody could plan their deployment, maybe plan when they would upgrade, figure out how they would expand their deployment with new projects, whatever would be relevant for them in managing their overall OpenStack installation. So we're going to spend most of this conversation today talking about that last piece and what the current roadmap looks like. But I'm just going to give a little bit more context for how we capture the user stories as a way to bringing input into the road maps. So the working group was formed and we reached out across the community and have, at this point in time, attracted and have participation from the folks you see on the slide. And one of the things that's interesting about that is these companies represent about 80% of the development resources that are available inside of our community today. So there are folks who can have relationships with enterprises that can be a source for requirements into the community. And then they also have resource development resources so they can help us to implement those within the community as well. Over the last six months, the product work group has really brought up, I'd say, its infrastructure. So we started out by defining really a workstream, a six-month cycle that goes ahead and syncs up with the overall development cycle here in the site of OpenStack with six-month release cadence. And then from there, we defined what is a user story? What's the information that we need to have within it to be able to have a sufficient detail so that it's actionable? And also including why that user story matters, right? What's important about it and how's that going to impact and why it's important to the end user that we got that from? We brought up a repo and we now have gone ahead and started committing user stories into that. We went to the ops summit in July in Palo Alto and observed and talked with the operators there and sourced more user stories. So today we have about 20 plus user stories in our backlog and we have four high priority user stories that were in the process of moving forward from a gaps analysis, blueprint spec, bug identification, and then into development. And then we also established cross-project liaisons. That's the mechanism inside of our community for how we coordinate across different teams. So whether you're Nova and working with folks in Cinder, they're gonna have cross-project liaisons. And so the product work group, we established project liaisons for 11 projects. It's only 11 because that's all the bandwidth that we have inside of the team right now. Ideally over time, we'd like to go ahead and be able to expand those relationships because we know that more and more projects will be important to us in implementing and delivering on the user stories in the releases. We also formed the roadmap subteam and in Vancouver produced the first roadmap and this is the second generation for the Liberty release. And then of course we learned a lot along the way during the six month cycle. And we actually, after this session, we'll have our working session here in Tokyo to talk about our learnings and figure out how we wanna evolve our work cycles and our processes to go ahead and continue to move forward. I'm just gonna cover this very, very briefly. But this is the flow of a user story. So we have three different stages for its development. The first one is draft. So that is basically just having the template filled out with a very minimal set of information in the correct format and getting it posted in the repo so that it can go ahead and pass all of the checks. So at that point in time, we have that information and we can go ahead and start to look at it and improve it and add more detail to it. Once it's got that base level information in the right format, it moves into the proposed stage. At that point in time, people inside the community can comment on it, can go ahead and help us to make it better, and at the point in time where we have somebody within the product work group who's willing to take ownership of that user story, meaning that they're gonna commit resources to taking that user story to the next level of being able to decompose it into gaps analysis, blueprints, specs, and bugs, it moves into the track folder. And at that point in time, we start to bring up essentially a spreadsheet like device to help us understand what are the projects that would be involved in the implementation of that user story and what are the capabilities that need to be implemented in those projects and then what are the blueprints, specs, and bug reports that would need to be addressed in order for that capability to be realized. At the same time, we also define the cadence around the road maps, how frequently we would go ahead and provide roadmap updates and aligning those with the release and the design cycles inside the community. We've basically come up with a quarterly release cycle. So what you're looking at today will go ahead and be reflective of the Liberty 3 milestone. So Liberty coming out and then projections from talking with folks inside the community, the PTLs and the project technical leadership around what are the themes that they would expect to be the highest priority in the Mitaka Design Summit so that we can start to look forward a little bit and even looking forward to what would be the themes that they expect to carry on into the end release and packaging that up into a roadmap that we can go ahead and start to share. So that's what we're gonna walk you through today and then either at the very tail end of this quarter or the first part of next year, we'll have another update which will include the results or the output of the Mitaka Design Summit that's going on here this week to bring more detail to the Mitaka release and probably more detail to the end release I would expect as well. And so you'll start to see that cycle. A roadmap come out with a release and another roadmap at the conclusion of the Design Summit and move that through so that we'll get four roadmap updates a year. And so with that, I'm gonna turn it over to Shamile to go ahead and walk through the roadmap for Liberty. Thank you, Carol. So before we begin, I wanna give a huge thank you to the product work group roadmap team that helped put this data together. It was a lot of work over intensive amount of hours over weeks basically so thanks you everyone. And before we start of course, because this is a roadmap slide, I have to have a disclaimer slide too. And on the disclaimer side, this is an open source project so disclaimer isn't the standard disclaimer but more about the fact that because open source communities rely on people working together and priority shift, resources shift, some of these things might actually shift because of that. So having said that, what does this content actually cover? So the people that were shown on the previous slide worked with about 20 projects to collect data across three releases with them. So the first thing we did was we looked at what did they just deliver in Liberty? So validating what was the Design Summit from last year or last summit, sorry, and validating with what the actual output for Liberty was. We then also spoke with them about, as Carol said, what are you planning to do in Mitaka? And then once they answered that first, we were like, okay, that's great, now let's try putting this further, what are you planning to do for the end release? And so with that, what we got is a good set of mix, if you will, of features and functionality that these teams are planning on working on across multiple themes, which we'll talk about in a second. And we also got the important picture of what themes are important to these projects as well. So what were the themes that we were asking on data for? So the themes were defined as these five things, scalability, resiliency, manageability, modularity and interoperability. And a quick definition of each one is scalability is something that impacts the scale at which the service can operate, whether it's number of transactions it could serve, number of engines it can have for scale out, load balancing, et cetera. Resiliency is anything that impacts the high availability or the ability to recover from failures when they do happen for a given service. Manageability is any item that improves operations or user experience of that service. And so generally, if there's a feature that doesn't fall within the other four themes, it will probably fall under manageability, which as you'll see in the next slide is the most common theme, release after release. Modularity is another theme which is growing in importance and actually has a lot of traction in the community around it as well. Modularity is something that changes the architecture of the service that will result in either being able to innovate in that service in a more agile manner or take code that exists in multiple places and being able to kind of centralize that in one place. Again, both of those things impact the velocity at which a team can continue to innovate in a project which in turn helps them deliver the other themes much more faster too. The last thing here is interoperability. And the interoperability definition that we use is slightly different from interop which is being used as the federation type of a definition open stack clouds. Interoperability in this theme really means federation. So being able to have a common experience, if you will, across multiple open stack clouds, being able to have separate clouds, have compatible APIs for example. The other piece is service dependency. So basically a service not creating or duplicating a functionality in its own code base but calling another open stack service to help it do its job. And then the last one is compatibility. And compatibility here meaning that if I have service X and service Y and service X is an older version, can I be backwards compatible in communications and maintain that experience? So with that, what the team did was we actually put together three themes or three view types I should say. The first one is a 10,000 foot view. And the 10,000 foot view is the highest level view. So here we don't go into details about what the project teams worked on. What we're covering is across all three releases, what were the different themes that the team has some work planned for or has completed work in already. And so in this for example, it's a really good way in one slide to be able to get a good view of where's the focus in the community, right? And just to show how this data could be read, these are some observations that you can make from just looking at this slide. So for example, as I mentioned earlier, manageability is consistently almost every project did something to impact manageability. Likewise, I wanna focus on Nova as well because if you look at Nova, Nova is working across all themes, across all releases, or and there's some information that's missing there because if you look at the dot, dot, dot, the dot, dot, dot basically means that the PTL was in a point where he said, I can't really predict or give information on what's gonna happen in this release. So basically the triple dots mean that no information was provided. However, if we look at Nova, there's a bunch of check marks there meaning there's planned activity or work. Likewise, the other interesting thing here is we can look at projects and see what's important to them from a focus perspective. So Solometer is focused on scalability because they're working on it across all releases that they reported against. Likewise, for example, heat is also focused on scalability and glance is focused on resiliency. So this is how you would use this data. And as I mentioned, some projects didn't report all information for all three releases. So in those, there's a good trend because they are working on a theme across multiple releases that they might work in that theme for a future release as well, but we just don't have the information so we can't say for sure that they will continue that work. The next view is one level down. And so here what we're doing is we're giving a one sentence or one statement example of what was some activity that the team did or is planning on doing that made us check that box in the previous slide. So basically, this is the data behind the slide that you just saw a moment ago. And it's really good to see it in this view. So this view should be read more from a release perspective. And here, for example, we can see NOVA has a really important enhancement in progress right now which is Sol's v2 which directly impacts the scalability of the service going forward but it's a pretty big undertaking as well. So from that perspective, NOVA is starting the sales v2 implementation, continuing it in Mitaka and actually they probably might complete either in Mitaka or more likely it might actually be completed in NOVA, in sorry, in the end release at which point it might be completed to where we can move from v1 to v2 for sales. Likewise, if we look on this slide, here we can see COLA is a good example here. So COLA was actually working on all themes in the Liberty release. And one interesting point here, by the way, is if you look under Manageability, the COLA team put together containerized images for 90 open stack services or components of services across five distributions. So the team was really busy in Liberty. In this slide, we can see for example that Keystone has improved Furnet token support in Liberty and then in Mitaka they're actually planning on moving to Furnet tokens as default. And this was actually an interesting topic because we just went to the operator summit as well to get their feedback on questions that the project teams wanted to ask them while everyone was gathered in one place. And one of the questions there was what type of tokens do you use and everyone pretty much said that I plan on using Furnet. So that means that if the Keystone team later decides to start looking at potentially depreciating other token types, they might have good support to do that. But the first step is to get Furnet token support fully functional and so it can become the default. Over here is another example of a multi-release heavy lift item, which is what HEAT is doing with the convergence engine. So the convergence engine is a change from their existing engine base where they can actually scale out the engine to load balance and distribute the load for the stack management across multiple controllers. And this will be actually coexistence so the existing engine type will be available but then there'll be a new engine type called Convergence that will be coming out as well. And in Mitaka, they will continue to go towards this goal of Convergence and then in the end release, they're hoping that they'll be at a point where they can start considering potentially making it the default at some point as well. And then on this slide, we can look at the fact that Trove has actually undergone a change recently in their MySQL support to where they refactored the guest to allow new variants and these new variants now allow us to run HA MySQL clusters in Trove. So again, these are changes that you can see just by reading across this view. And again, we just covered 20 projects across three releases in five slots in this view. So again, this is one level down so now we can actually see what work is being done and we can track projects against releases as well as projects against themes in this view. There's also another level of detail which is what Mike will cover and then he will also tell you where to find this content and more information about it. Sure, thanks a lot. So the last view we took here is what we called a 100-foot view. So in this case, we're actually going directly down to effectively the blueprint level and we're looking at what the projects are working on and we've provided a readout for all the projects we're covering in this roadmap and a summary slide for each. So part of what I'm gonna do here is I'm not gonna show you every one. We have these online, I'll be providing a link to the whole presentation including the 100-foot view for every project we covered. So you don't have to grab pictures or take furious notes from these. But so for each project, this is a good example of one particular 100-foot view that we built. These were built with the help of the entire product working group that you're working on the roadmap presentation. So we actually went, we talked to each of the PTLs, we looked at the launch pad and actually mapped these things into particular slides. We created one for every project we're tracking. So if you look at the slide, one of the things you'll see is in the project snapshot, we have a link to the Wiki for the particular project. We actually have Stacolitic's data for contributors and for the companies that have contributed in the cycle to this particular project. And then we show you the most important specs and blueprints that are broken out across for the Liberty, for Mitaka and then as possible for the end release as well. In many cases, you've taken input from PTL but also directly mapped against the information you would find if you go in launch pad and you look at the blueprints that the PTLs have mapped against these specific releases. So this is another example. In this case, Magnum, we see is a newer project. You probably saw some different sessions on it handling container networking at OpenStack. Again, you can see we have a link to the Wiki. We have the contributors and the different companies involved and the different specs. In the case of Magnum, since it's an earlier project, there's actually still zero specs directly tied against the Mitaka release, although there's quite a deep backlog of them and we use input from the PTL actually to talk about the roadmap and the specific features that Magnum will be looking at in the upcoming cycle. And of course, in all these cases, this could vary even as of today as the design summit kicks off, this data will start morphing around and we'll be doing a roadmap update to update it from there. So this is a pretty important link to grab. So we have placed this entire presentation along with all of the 100 foot views that we've created online on OpenStack.org. This is a roadmap lending page so we talk about the roadmap and that includes the latest link to this presentation that we have and we'll be including future updates to it as we refresh this with different cycles. It includes the projects we covered, the themes that Chamal talked about and then the 10,000 foot, 1,000 foot and 100 foot views spread across the different projects. And you said right now, we're covering a set of core projects and we're expanding this across the big tent and as time goes on and we have more people involved, we'll be able to cover more and more of the big tent based on our teams bandwidth. So the last thing we can leave you with is one, a set of links to one, learn more about the product working group itself and our wiki, the user stories that Carol talked about, if you wanna understand where those reside, how to get involved in that process. We'd love to have input, we'd love to have more people involved generating user stories, helping us track them along the way. We'd love to have more people involved in the product working group. If you're in this session, you probably care about the roadmap for OpenStack. If you'd like to help track that, influence it, connect some of our end users with the features that are going on in OpenStack, this can be a great way for you to get involved. So just, our meetings are open, we run them at RSC. Feel free to join and we're happy to help you get involved from there. So thank you, Mike. So the next step for the roadmap data itself was as we said, we didn't cover the full content because as you saw, there was a lot of content, but the content is available. So we do encourage you to go and download it at your convenience. The next step is the data that you saw here was collected at the Liberty 3, between Liberty 3 and the launch of Liberty actually. So the next step is we're actually gonna do webinars with all the project team leads for the projects that you saw here after, for the Mitaka release, after the design summit. So probably within the next two to three weeks, we're gonna go back and talk to all of these teams, get a refreshed view on Mitaka, hopefully N, and re-update this slide deck to take in the account of the outcome of this week, actually, from the sessions. And also, the other interesting thing is the way we're gonna do that is what you're gonna do in webinar format. So that will actually be about five to 10 minute videos for 20 projects that you can consume on your own time to not just learn about the roadmap for that project, but also learn about what is that project, what's driving it, and what are they hearing from the people that are using their services. So again, thank you for coming. Any questions? Because we do have some time left. Will the link for the webinars be posted on the roadmap landing page? Yes, they will be. I was looking at Heidi Joy over there. So Heidi Joy is from the Overstack Foundation, and she's the one who helped us get that on the roadmap page. So yes, they will be there. And actually, that's a great point, because what we probably will end up doing is just like on that 100-foot view that you saw that Mike shared, we have the details as Mike pointed out for each project, but over here, this is a link to the Wiki page for the project as well. And here is a link to stack-a-lytics data to see who's contributing to the project. So the natural evolution would be to also include links to the Mitaka webinars that we're doing in this page as well in the future. Any other questions? All right, well thank you so much for coming, and hopefully you can in...