 Good morning everybody. My name is Scott Drennan and I'm a member of the newly formed product working group within OpenStack. And we're a bunch of people who got together who are active in the OpenStack community but we're not people who generally write code. That said, we still have influence over people who write code. So we'll talk more about what the product working group is a little bit later but what I'd like to focus on right now is a glimpse at the roadmap. What we're going to do, I'll talk a little bit about what we're doing. I handed over to a couple of my co-presenters here and then there will be time for questions and discussion at the end. So we have Mike Cohen from Cisco, myself, Scott Drennan from Nuage Networks, Shamile from EMC, and Sean from EMC. There's only four of us standing here but there's a longer list there. This is one of the sub teams within the product working group that solicited the information from the PTLs and the core teams to develop the content. And as you can see, it's a pretty broad spectrum of vendors and companies involved in OpenStack. There are lots more people involved who aren't on this list. So this is the ubiquitous and obligatory disclaimer slide. No warranty expressed or implied. You see that on every roadmap but it's a little bit more important here because of the nature of the OpenStack projects. OpenStack is open source. OpenStack is also a community. But what that means is there's no one group that says this is what OpenStack is going to look like for the next three releases. It's a very organic process. And so what we've done here is reflected back what the PTLs have been telling us. But even for the PTLs, some of them call themselves the chief catherter of NOVA or the chief catherter of Neutron. So there is no one roadmap. That said, with the disclaimer out of the way, one of the reasons we did this was again because of the diversity and complexity of the OpenStack community. There's lots of different inputs coming out the PTLs from the user committee, from the ops groups, from individual people, from individual developers, from the various working groups that are focused on segments where OpenStack is interesting, and from some specific working groups to solve cross-project problems. And one of the key goals of the product working group is to facilitate a consistent, coherent feedback loop between all of the different parties involved, between the PTLs, the core teams, the developers, the user committee, ops, everybody. There's another session on Wednesday which we'll talk about later to discuss this in more detail. And we're certainly not doing this alone. There's lots of work within the OpenStack community to try and bring this together. As OpenStack has grown, it's become a much bigger project. There would never have been this many people in a room a year ago, two years ago, three years ago. So it's become necessary to do this sort of thing. So enough background. What did we actually do? So we were going through a process gathering feedback from the PTLs. We went and looked at what is OpenStack going to look like for the next 18 months. And this is from the viewpoint of the PTLs two to four months ago. So these things always change. But we asked, what are you delivering for Kilo? What are your plans for Liberty? What are your plans for the M Cycle? And another key question, what can we do to help you? So we'll be talking about the first three here. The fourth one we'll have to wait for another session. So next up is Mike, who will talk a little bit more about what we're doing. Thanks a lot, Scott. So as Scott mentioned, we basically did these pseudo interviews with the PTLs and asked them a very definitive set of questions. What are you working on different releases? Then we had the problem of once we got this feedback, what do we actually do with it? The feedback ranged from a list of blueprints to high level initiatives, to initiatives that span across multiple cycles, to things that were definitively mapped to specific releases. We got a very broad range of feedback and it was actually quite a bit of work to figure out how to structure it and how to lay it out in a material way. And ultimately what we came up with was a framework that broke it down into three different views. One was essentially a 30,000 foot view where we sliced it across a number of different areas, scalability, management, reliability, new functionality, etc. And mapped what each project is working on or essentially where the focus is across these different projects in these areas. The next level of distillation was what we call the 10,000 foot view here. Essentially what we tried to do is on a segment of slides you'll see in this presentation, map the different features that projects are working on across multiple releases and again into these specific areas. But ultimately be able to map them back to concrete projects that are being driven within the community. And then finally, the last set of material we have that we were including in the deck and we're not going through explicitly today is essentially the 30 foot view. Really documenting what we heard from the PTLs, what areas they're working on, and how that spans across different releases. So we're gonna be including that in this deck for everyone's background going forward, but we're not going through each project specifically here. So some additional comments before we get into some of the specific data. One, as we mentioned, the data was compiled based on input we heard from the PTLs, although we did some distillation of it. So there's obviously some degree this is colored by our own input and our own, some of our own thoughts about how to present this in a meaningful way. It's also important to note that it's really a glimpse at the roadmap rather than the roadmap itself. Because what we tried to do was extract one important priorities and actually bubble them to the top is to put this in a form that we knew people could absorb. If you were to look at all the blueprints for every project, something we already have today, you would find that it's actually a very difficult set of information to digest. And we wanted to come up with a more digestible form. It's also important to note when this happened. So we started gathering this data around the time of our mid-cycle meetup. So we focused on a set of projects that existed in OpenStack at that time. The reality today is after the big tent model came into play, there are actually more projects than this. And we intentionally didn't cover them, partially to manage the scope of what we were trying to achieve and develop the first set of data. One of the other things we've observed that I believe is important going forward is, as we dug into this, we actually found that there might be value in showing the roadmap in two forms. And what we might think of as a user-facing roadmap, where we could show users and operators new functionality or key areas that are being worked on. And behind that have almost a developer-facing roadmap. So what we found was there were many backend features that are incredibly important that are being worked on, that are major initiatives. And in some cases, we want them bubble to the top. And in some cases, they actually confuse the picture in terms of distilling a 10,000 or 30,000 foot view in terms of what's really important and what's being worked on. So in this view, we're actually showing a consolidated view of everything we've learned. I think going forward, we see value in potentially separating out what will end users care about and how will they be impacted by the work going on in OpenStack versus what are developers actually tracking and doing? So with that in mind, let me actually show you the first slide in our view here, which is the 30,000 foot view. So what we did is we actually sliced the data across a couple of different dimensions. Scalability, resiliency, manageability, modularity, and functionality. It was actually intentional to put functionality last. So obviously in OpenStack, this has been one of the key areas where almost all OpenStack development is focused on, what new is in this release? When is it coming? What are the new shiny object features? I think as OpenStack's matured, we've actually realized that there's value across the board in some of these other areas, scale, resiliency, management. And we wanted to demonstrate how the different projects are working across them. So let me show you some of the things we figured out as we started looking across this matrix. Obviously we saw in Kilo a huge focus on functionality. And I think as the Liberty and M plans materialize, we'll see that as well. There'll always be new functionality coming in OpenStack. But we also saw things like different projects having different levels of focus. In the NOVA project, there's a very strong commitment here to building scalability. And we heard that for every one of their answers was focused around increasing scale. And there were other projects like Keystone, which actually had features that fall into all of the different buckets that we were categorizing. You can also dig a little bit deeper here and you can see things like, in the Kilo release, a lot of the more mature projects, NOVA, Neutron, Keystone, etc., were focused on scale. So there actually has been quite a commitment to increasing scalability. And we can also see how some of that will also shift towards management and reliability and modularity as we get into the L release. Again, our goal here was to give you views where you can slice things both horizontally and for a project and understand that a high level where the focus of the different projects resides. Now let me hand off to Shemail and we can actually show you the next level down of depth. Good morning, everyone. So thank you for the great summary, Mike, and how we compile the feedback and what we did with the feedback. For this level, the next level down, the 10,000 foot view, if you will, we're going to shift focus a little bit. And again, not to play favorites, I can either talk about all or none. And for the sake of time, I'm going to talk about none because there's too much information here for me to actually go through everything. But what I do want to touch on is the view that Mike showed you earlier is a good view to get a top down level of what themes, like scalability, resiliency, etc., a release is working on. And a project is working on. At this layer, what we're really focused on, the best way to read this one, is read it horizontally as a release level roadmap. So in this level, what you want to do is you want to look at kilo, and across kilo, we can see that there are things done across all aspects and attributes. And we can see a consolidated view here, actually, of which projects worked on which specific blueprints and specs that impacted that area or that theme. The other thing I want to touch on real fast here is the definition of the themes. Again, just like we took the PTL feedback and built our own view using that feedback that we got, we also had to come up with some definitions of attributes and themes. And again, as we move through our work group process, these will solidify and there's other teams that we're working with to kind of understand what are the themes that we want to kind of classify going forward. But for now, what scalability implies is it implies any work in the project that is impacting the scale at which you can run that project. So basically supporting more compute nodes, more API front-ends, etc. Resiliency is focused on anything that either improves the availability of the service itself or improves resiliency of the actual data path, for example. Manageability is focused on all things that are operations and user experience focused. So if someone does a simplified workflow and makes something simpler to deploy like an instance, that would be a manageability item. And then modularity is actually more of a back-office or back-end type of function where modularity is really referring to a notion of, for example, Neutron recently took the services they had and broke them into sub-projects. So that's modularity in action, which basically allows people that are domain experts to work on sub-projects that are of interest to them within the larger networking umbrella, as well as it gives the capability to find and resolve bugs faster. So modularity is all about a decomposition of the project and service itself to make working on the service and developing against the service easier. And the last piece is functionality, of course. And functionality has two sets here. So it's either new functionality or it's enhancement to an existing functionality as well. So again, hopefully the slides will be available later, but I kind of wanted to give that background on what the themes are and how they were determined for now. So the 30,000 foot view was one slide. The 10,000 foot view is actually three slides long. And so here we can see that across the board, most teams, because Kilo was in flight and Kilo is now delivered actually, had a very good and detailed understanding of what they were going to be doing in Kilo. A lot of teams had ideas that they want to do in Liberty as well. And this is where the roadmap disclaimer that we had earlier comes into play a little bit as well. Because the feedback we got was as project teams and as people who are building services for the OpenStack platform, we have ideas that we want to focus on in the next release. But of course, until the design summit happens, which is happening this week, nothing can actually be committed in terms of the spectrum blueprints. So a lot of the ideas in Liberty are much more about focus areas and things that the team would like to start working on or continue working on. And then with M, you can see that we got a lot less feedback in M, because that's even further out. So that's one of the things that we're trying to hopefully encourage is to make this information available and publish it. So that way, at least we as users and operators of the platform can see directionally what the focus areas are at least. We don't have to get into specifics of what features and functionality per se, but at least where you're headed from a project perspective would be a good thing to display to everyone. So again, continuing on, this is the next set of projects. And for each slide on the top right hand, you can see which projects are actually covered in the slide. So per slide, there's about five projects that we're covering roughly. And then the last one here is, of course, wrapping up with some of our other projects in here. So here you can see that some projects like Horizon and Triple O, for example, have already started thinking about L, because they've got things that are going to be taking multiple releases for them to do, more or less. So a lot of the feedback we got in M level, was more about themes and areas versus actual implementation. So a lot of the M release stuff is either continuation of things that are planned for L, or its ideas of we want to work on scalability. And nothing more than that for now. So with that, I'll pass it on to Sean Nguyen. Thank you, Shumail. So if you were wondering how features, functionality, or improvements to OpenStack come to play, they actually start off as a specification. And you can see here in this table, a list of projects which have released different specifications, which have matured into blueprints over time. And then in the end, eventually get implemented in the form of new code that gets merged into the tree and deployed in your data centers. So you can see here that a number of projects have existing specs repos, and you can find these existing on GitHub today. They're available per project, and it's a resource where you can actually iterate on the specification for new features, new functionality. And in addition, when it comes to release time, for example, we just dropped the Kilo release. As Kilo was released, there are some specifications which may be listed. And for example, the Kilo specs repo, which may or may not have made it into the code. So it's a good way to go in and see, based on the release notes, along with the specifications to figure out what features and what functionality have actually made it into the code base. And then in addition, a number of projects are already hosting their Liberty specs and nobody's actually hosting the M release specs yet, because obviously we're not at the point of planning for that release. But if you'd like to be involved in any of the specification plans for Liberty, that's actually going to be developed as part of the design summit here held for developers and operators. So that's another way that you can actually help to shape OpenStack. As an example for some of the specifications and, sorry about that. So if you wanted to see some of the 30,000 foot views that are available for the different projects themselves and you wanted to get more detailed information, for example, here's the 30,000 foot view of what was released for heat. We did not include every slide for all these projects, because to be honest, there's just too many of them to cover. All these slides are going to be available for you to download. And the actual presentation that gets uploaded will include every last one of these slides that we've mapped out for you. So you'll be able to actually get a good detailed view out of the presentation and see what specifications were implemented and then also what's planned for upcoming releases. As you can see here again, the M release, not a lot planned, because it's just a little bit too far out to understand what we're going to require for that. And with that, I'd like to say thank you. So, few notes. We are holding a cross-project working group session. That is going to be held today, 3.40 PM in Room 212. We're looking for more people that can actually get involved in the working group. People who can help to influence and kind of drive the roadmap for OpenStack, not necessarily drive it, but get understanding from the project technical leads as to what the roadmap is. And better communicate it to the community, to the users and vendors that are participating in the space, so that we can have better messaging for the OpenStack community as a whole. And then also tomorrow, we're having another presentation, the State of OpenStack Product Management, where we'll actually talk about the processes and everything about how this group came to be, where we hope to go, and how you can help to get involved. So with that, thanks and. Yeah, so thank you so much for attending. I think we got some time to do Q&A as well. But before we go there, I just want a quick show of hands. So what's this content as far as how we express a useful thing to have going forward? Do you see value in what we did here? Okay, good to know. And Carol, who's going to be part of the next session on tomorrow, will actually be able to go a little bit deeper in questioning of views and how can we better express the information, so on and so forth. But thank you. I mean, this is good validation and encouragement. I think you put a lot of effort into building this. So before we go into Q&A, I know I saw a few product working group people in here. So can you stand up for one second if you're actually part of the product working group already? That's a go in. Okay, so even though we presented, it was a team effort. And so as we began Q&A, we might answer the question or any of the people here that are in the room might actually chime in as well with answer. So with that said, if you have any questions, please step up to the mic right in the middle of the room. Thank you. Okay, yes, if you don't mind, thank you. So you said a lot of you are not developers. So what kind of people join the working group and are you looking for new members to join the working group? So we're definitely looking for new members to join the working group. Many of us are part of product management teams that have influence over OpenStack developers within various organizations. But that is by no means exclusive. It's really, are you interested in trying to shape, communicate, feedback the OpenStack product to direction from a non developer centric kind of approach? Absolutely, I mean, even on the stage right here, we've got product management, I'm a technologist, we've got an architect, we've got an operator. We've got a multitude of perspectives and roles represent here. And so this is why it's the product team versus, because we want multiple perspectives, we want multiple people, including operators and users to participate. So that way we can make sure that what we're delivering both to the users of the platform, as well as the information we're sharing across projects, is as meaningful and covers as many perspectives as possible. So if I'm interested in a particular subgroup like Cinder, so should I join that working group, or should I join the overall OpenStack working group? How does it work? So with the product we're working group at least to date, we're not micromanaging the individual projects, right? The PTLs are running the projects. We're looking at one kind of, how can we help understand user requirements and feed them back to PTLs and facilitate cross-project communication. If you're interested specifically in what Cinder's working on, it's best to engage with the Cinder group. So maybe I'll ask a leading question. When we do this again in Tokyo, what would you like to see different than what we presented today? How would you like to see an OpenStack roadmap, multi-release roadmap presentation that's different than what we have? Anybody have any comments, suggestions? So more charts, less text. Okay, any other comments? All right, thanks everybody. Thanks everybody. Thank you.