 Good afternoon, everybody, that I can no longer see because of the lights. My name is Pete Chadwick. I'm here with Arkady Konevsky. We are members of the OpenStack Product Working Group. This is a community effort to help guide, especially in the area of cross-product, to try and define use cases that span multiple projects and work with the user community to help represent requirements and demands into the overall project. What we wanted to do today was talk about some of the ways that we try to structure the discussion with the community and with the technical committee on how we should be addressing key objectives in the roadmap. There's a separate session tomorrow that goes into much more detail on the roadmap, but what we were trying to talk about today, what we call themes. I think you heard Jonathan talk a little bit about themes in the kickoff this morning. The keynote, what we're trying to do is explain how we use themes, how they're important, and ideally get feedback from the community as to whether this direction is where we want to go and whether we need to add some additional changes. So first of all, this is a roadmap discussion, this is a community, things change rapidly, so your mileage may vary and all that sort of thing. So what we want to do is, as I said, we're representing the Product Working Group. I'm not going to introduce all these people, but it's from a number of different organizations, both providers of OpenStack services as well as consumers of OpenStack. And we meet on a fairly regular basis, and we have weekly, bi-weekly calls to talk about where the overall project is going or where the overall OpenStack project is going and then focus on specific sub-areas that we think are particularly relevant. There are a number of sub-groups on the Product Working Group. For instance, there's a group focused on onboarding commercial ISV offerings. There's a group that's focused on specifically enterprise requirements. There's a telco working group that feeds up into this as well. So we're trying to bring forward requirements and concerns from the broader OpenStack community to help guide projects, especially when, as I said, there are specific use cases that span multiple projects. So I want to talk about, as I said, themes. So I thought we'd start off talking about is what is the theme, how do we use it, and why do we think that it's important? So first, from our perspective, a theme is a high level objective. And you heard Jonathan talk today about user experience. So the question is, what is it about user experience that we can ask the various technical teams to go focus on to make improvements as we go through the various six month product cycles? But it's not really, originally I wrote this and said it's not features. That's not strictly true. It can be a feature, but it's not just features. And it's not just like, I want Nova to be able to do X, Y, Z. It's I need to have Nova work with Horizon work with Glance to deliver this particular capability. And they all need to work in unison with each other to make the thing make sense. So for example, I want to be able to manage. I may have a use case that says I want to be able to improve the manageability of multi-region clouds. And that's going to impact a number of different projects and how do we define that? And it's most specifically, it's almost never project specific. Again, sometimes it could be very project specific, but usually it's a cross project effect. Because you think, okay, user experience, well, that's horizon, right? That's just the dashboard. That's what the user sees, but not really. And it can also be, if a user writes an application that takes advantage of an API, you don't want that API to change in the next release and break his application. That would be a bad user experience, even though it has nothing to do with the horizon dashboard per se. So how do we use themes within the OpenStack community? So again, it's primarily about unifying a set of efforts and a set of messages that we can deliver to the technical community. And then we can also use that as we go back out to the market, to the user community and the market at large to explain what it is that we are focused on. And the one goal that we're trying to drive is helping prioritize work efforts across projects and across releases. So you'll see, we've got a slide later on that Arkady will go through that talks about how we're tracking specific themes, showing how individual projects are addressing those themes. But it's a snapshot that's based upon where we are with Metaka. There are efforts that'll go into Newton, there are efforts that go on to Okada. We really started this back in the Liberty timeframe, so it's still a process that's evolving. And the discussion that we want to really go through today is, how do we kind of continue to make this relevant to the overall community? Which is the last bullet here. So how do we pick themes? To some extent, we're trying to identify non-feature issues that perhaps are limiting deployment. So for example, if there's going back to user experience, if someone says, well, I deploy this, but every time, you know, every six months an API breaks, I can't trust this for deploying production workloads because it's just not stable enough for me to do that. That is the kind of thing that we could apply a theme to and say we need to stabilize things, we need to make them predictable so customers that can then go deploy them. We try to focus on things which can address multiple different use cases. So it's not just about enterprise, it's not just about public cloud. We try to focus on things which go across multiple, multiple areas. So there may be some requirements that the NFV team is coming out, driven from the telco working group, that aren't necessarily relevant for the enterprise working group and similarly for the public cloud. So we're trying to identify themes which can really span across all of those different use cases. One of the things that we want to do is encourage more direct feedback. So we're hoping, you know, there'll be a quiz at the end of the session where we ask you to tell us what's good and bad about the themes that we've been running against so far and ask for feedback on that. It can be either you can either feedback directly or anybody's welcome to join the product working group mailing list and provide us feedback that way. And the one thing that we're starting to do now, and this is something that Arkady's been working on, is we've started to work with the team to identify different roles of cloud consumers, whether it be an end user, whether it be an operator, whether it be a cloud architect. We're trying to define the different roles that someone would have and how we map against those roles as to what needs to be done in OpenStack. And we're starting to map the themes against the roles. So the idea would be to say, you know, obviously if there's a particular theme that should be important to all roles, that may be a little bit higher priority. So for example, one of the themes is security. And that's important across every role as far as we can tell. So now you have to crawl down in there and say, well, what's security mean to an end user versus what's security mean to a systems administrator? So these are the themes that we used when we talked about the Mataka roadmap. So I'd asked for a show of hands, but since I can't see them anyway, it's kind of pointless. But this is what we rolled out with the roadmap in Tokyo when we presented Mataka there. So you can see, I'm not gonna read through this, you know, the themes are scalability, resiliency, modularity, interoperability, and manageability. It's pretty broad, pretty straightforward. One of the things that we found is we looked through some of these things like manageability, we had too many things within the single theme. So we split out and said, okay, so manageability really has two parts. There's one section that's really focused on how do I operate the cloud? How do I set up the cloud? How do I maintain the cloud? And there's a separate section, which is really about the user experience, whether it's the end user or whether it's the administrator. So one was about tools and how do you build tools that make it easy to manage the cloud? And the second one was about how do you make sure that everything is working together in a consistent fashion so that the user feels that they've been getting more value out of the cloud or it's easier for them to consume for their particular organization. So one question just quickly, do these make so far, I just wanna take a, does this make sense to everybody? Is this sort of not? I mean, this is something that we think is useful. We wanna make sure that it's useful for the community in a way to describe things. So we've got a couple of new themes that we think we wanna bring forward. And again, I think those are something that you're really teasing out of manageability. Obviously security and stability, you wanna make sure the cloud's secure so nobody can hack into you so that you don't have to run the risk that you've got multiple tenants within your cloud that one tenant can see what's going on with another tenant. And then how do you just secure everything within the cloud to make it robust and stable? And then how do I make sure that I got more stability, especially in things like APIs? So if my cloud today runs one way, I wanna make sure that the month from now it's gonna run the same way so that I don't end up breaking applications. So again, we'd love to get feedback on that. We'll run through a couple more discussions and then we can open it for questions. So as I said, if you've got an opinion, if anyone wants to raise their hand and say this is terrible, this works well, this is irrelevant, yes. You're looking for potential new themes in addition to these or you're looking for specific feedback on- Or do any of these not make sense, so either way. Okay, well I'm wondering if there's one about continuous deployment. And I think some people are starting to want to avoid the pain of the forklift upgrades by continuously deploying code. And then, but the way that the community works with DevStack and CI, it's always like a fresh install test. And then there's some upgrade testing that goes on. So it's really more of a question if this is an area that we need to start to look at as a community is to be able to continuously deploy OpenStack from master and identify periods where there would be disruption, whether it's a database upgrade, that kind of thing. Sure, so I think that from a theming perspective, I would put that under stability. More directly, we have a set of user stories that we're tracking on GitHub. And that is one of the user stories we're tracking on how do we make upgrades work better. Okay, stability would typically, at least my understanding would be, does it continue to run? Whereas this is really about deployment and being able to continuously upgrade. Okay, yeah, I agree, I understand the question. And as I said, we do have a user story we're tracking about continuous upgrades. This is one of those things, what's there's going to use case in a theme? In this case, themes, you need to have stability so that when you do those upgrades, things don't break. I think that's part of it, but I appreciate that. Anyone else? Okay, so there's a second question. What about other themes? So yeah, we can take back and see how we'll make it more explicit that we're tracking things like upgrade ability and to map it into one of these themes to make that more explicit. Okay, and that I'll turn it over to, oh, there's another one. Sorry, I know you're blinded by the light. One of the themes I'd like to see more work on is getting rid of a cruft in our code, like untested configuration options, some of which have been there for, since B or C release and actually don't work. Okay. We've certainly run into some in Cinder from when we split out and over. And I know there's some in Nova that have never worked. I know there's some in the worst, some in Swift that have mostly been fixed that have never worked. Okay. And I know I occasionally get support requests about, oh, I tried to twiddle this configuration option and it doesn't work. And you look at it and it's like, no, that looked like it never worked. Okay. But there's never any, I mean, getting resources to go through and clean up cruft and things or improve testing of configuration options or whatever is incredibly difficult from an organizational point of view because there's no obvious win from it. We've got a configuration that works. Why do we care about other configurations kind of thing? Yeah, and that's a fair point. And I would argue that that actually starts to fall under things like stability because if you've got code in there that's not being tested to mean our work, that's an accident waiting to happen. The thing though is not actually making a statement because unless you actually break these things down into what do we want to fix? Sure. You're wasting your, you know. Everybody wants stability, but what does that mean? So, and we do that. So thanks for making the clarification. What I was trying to get at was is that it's a fair point. So we can, we'll take that back as well. That's something that we can track as a separate discussion point or whether it's something we just make explicit as part of one of these themes. That's a fair point. I can turn now. So Duncan, let me try to answer that. So the themes are basically the place where we can aggregate multiple different user stories. So the flow which I will not get into today but it's on the roadmap as part of the roadmap presentation tomorrow is that we create a user story. From the user story, you know, there is some level of the rationalization going on, prioritization, you know, all of the user stories kind of map to the themes and then the group votes on them. It's actually open to everybody but usually very few people outside the product working group bother to vote on that. And then from that we start creating the cross themes blueprints or specs. Again, based upon the prioritization. From there kind of the next step down, we start creating the blueprints for individual projects which are all combined together to satisfy that user story. And that allows us kind of two things. It allows us to, you know, we as a product working group since majority of the developers, one where another are part of their organization we belong to, they work for the same company so the product working group de facto trying to prioritize things for them allows us to get there. So there is a lot of, you know, discussion of how we can put more resources behind them and what are the, you know, the right priorities. Again, the main goal, one of the biggest goal for the product working group was trying to help the PTALs to identify the priorities versus everybody is trying to hit them and saying, please do this for us. Here's a blueprint. Yeah, here's half a person to work on that but we need more. Not 100% sure if it answered your question but I think this will be great user story. So I would encourage you to submit the user story to the product working group and then we'll drive it as part of the overall, you know, as overall portfolio or user stories. So one thing which became somewhat obvious to us once we start looking into the more details of the themes is that some things are very tied together to the user role, to the role which the person is trying to do. They're not as much tied together interestingly enough to the use cases. So the same, you know, for enterprise working group versus for, for example, for NFV, for cloud native application and so on, all of them have similar kind of experience and similar kind of requirements but the requirements seem to be more targeted to the role of the person playing in the organization. So we kind of collaborated to this user working group and there is a Viki pointer to that to create some of the roles which we are identified. Actually, this is a small subset of the roles which people identified and we tried to kind of come up the definition and one of the main thing is that, you know, we realize that even from the, you know, manageability or for some of the other features, the requirements are very different based upon your role. So we come up with, you know, kind of extracted five roles out of that. You know, we have, as expected, everybody on the working group had different ideas, you know, is it the right number? You know, what are the other things we should, you know, do, should we break one of those roles into the separate, you know, into the separate things? So the kind of probably the most discussed was the user and user and that's kind of fallen to somewhat broad category. It kind of falls on the people who develop the application but also it falls on the people who are kind of running the application, managing the application in operation. Again, they're kind of targeted to the specific application domain. So the second role was kind of not straightforward came out but basically for every tenant, there is de facto a person who is setting up the boundaries of what the users within their organization can do. It could be department, it could be company, it could be a small group of people, it doesn't really matter but somebody is setting up the quota, somebody is setting up the policy and that's primarily such that the resources will not be abused. So somebody will not gonna go and, you know, spend a hell of, generate a hell of the expenses which somebody will have to pay later. So they're kind of counterpart, you know, the person they are mostly common associated with is a cloud operator and that's basically the role of the person who kind of runs day-to-day operation of the cloud and they're kind of supporting tenants directly. The cloud provider was kind of a strange role, at least a lot of us kind of could not really tease it out properly and that is basically the person who is running the cloud as a business. You know, the cloud operator de facto works for them to make sure it's operational but from the business point of view, it's a cloud provider who is providing the thing and they are integrating with a tenant operator to ensure that their SLAs are properly created such that cloud operators can provide them. Those are kind of more kind of straighter roles. The infrastructure architect has, again, couple of different views on that. So the most simple one, you know, here is a person who creates the company cloud, especially for the private cloud, this is a fairly well-defined role. There are the kind of the person who decides how the cloud will be built, what are all the components of the cloud and how it will be scalable in the future and so on. Notice that this kind of role, you know, if you go to public cloud, kind of disappears. Or at least it's not visible as part of this role. Finally, which was probably the most controversial role, but well-identified is that when you have a problem with a specific project within the open stack as a training, you know, you need really an expert to identify and help you figure out what to do about it. It may be, you know, a side effect of the maturity of the current open stack, but, you know, when everything else fails, every, you know, falls back to the developer who knows the code well enough to help out to understand how to remedy the problem. So as before, it's, you know, open mic. So if you would like to hear more about your feedback, do those roles make sense or remissing the roles? Or there is a kind of relationship between the roles and the themes which we try to identify here. So, you know, maybe we need to tear them down a little bit or maybe reorganize them differently. So any feedback you have on that would be greatly appreciated. For more details, that's Vicky for the open stack where all of the personas are defined. So kind of going back to integration between the themes and the roles, there is, you know, they're kind of orthogonal to each other, but there is something which we can easily tease out of that as Pete mentioned. Security kind of proculates for all of the roles. But what type of the security and what the underlying requirements and where they're implemented would be different based upon the role. So when we create user stories, you know, for the security, they probably have a role-specific components in that. So for us, this kind of information is very useful because that goes back to how we organize our user stories and, you know, what kind of thing we would like to create in a template so when we are creating user stories, we can identify what other things needed to be defined to help us understand what the impact will have. So any feedback on that would be greatly appreciated. You can do it here or you're shy. Of course, email, as Pete mentioned, is always great way of handling that. And, you know, it's on the Vicky so you can comment on the Vicky directly. Hearing none, I'll move forward a little bit. So when we did the first time, presentation Mitaka, we kind of looked at all of the project vision, the open stack, partially based upon their maturity, partially based upon, you know, how many resources we as a product working group have and kind of start working on them. So in this cycle, you know, we kind of matured from what we initial 19 project which we were tracking and creating the user stories for while creating the blueprints based upon the user stories for to much larger, much larger set of year now to 28. And some of the things you might think are a little bit outside of the scope, what we should be concerned ourselves. For example, the QA or stable releases, they're not really projects per se, but they're impacted, you know, the work we are doing or the requirements we're driving impacting them. So that's why we start bringing some of them into the, into the espaces of us when we are generating the user stories and work based upon them. So I'll give you a little bit of a teaser of what would be the preview at the roadmap because this is not a full roadmap discussion. This is the themes which drive the roadmaps. So again, based upon the themes we identified and the project which we are tracking, which is just a small subset of that here, we identified which of the functionality in each of the release we are driving. So needless to say, nobody's surprise is impacted on almost every release but based all of the things, except probably modularity. But as you can see, not every project have, you know, for example, work on interoperability on some of the other stuff. Again, some of that is basically a level of the maturity and if they reach the point where they need to address those issues or there's some other stuff need to be addressed. But by combining all of that information together we create the view for the users to identify where, what from the function, the high level functionality point of view where is, what's the current snapshot of the maturity of the overall solution. And then for each of the projects, we have a more detailed view where which right now we automatically generate the tool for that where we are seeing what are the functionality based upon the blueprints within each of the project associated with SIEM is being done in each release. We actually, you know, if you go to the roadmap discussion tomorrow, you will see the tool which automatically kind of goes through each layer at a time from the user's story to the cross-functional spec to the blueprints within each of the stories, within each of the project. And within the project, even the submission we share specifically associated with SIEM. So we have the full, you know, vertical view of everything which needs to be done and, you know, what the current status is with respect to individual user story for individual thing. So I'll stop. Well, I'll give the plug-in to the presentation tomorrow for the roadmap for our other brotherns and the product working group. And we would like to open the mic for discussion on any of the, you know, open questions which we hope to get some feedback on from the themes themselves, you know, how you would like to see them progress forward from the roles and, you know, which roles make more sense for you, which ones you think we should get rid of and, you know, how to progress that forward to which, you know, the kind of higher-level roadmap to drive the discussion forward. Again, I can't see anything since might have straightened my eyes. Just a quick question. Is performance across different components considered a theme or how do you think of performance? So what areas, I mean, because we were, one of the areas of performance we're trying to address is scalability. What is there some specific performance area you think is we're missing? There isn't a single definition, of course. I mean, different components. So, but different components, if they drive their architecture design implementations with performance in mind, that can become a theme. Okay, and sort of one way to think about an important component going forward, performance being an important driver for architecture and definition. Okay, that makes perfect sense. I mean, the closest we have right now for the performance, if you can call that, is there is a rally project. So let's see if I can go back, which we somewhere here. It's in the middle of the third round. So that's a project we added in the Newton timeframe for us to track. So rally consists of kind of three pieces. So one piece is ability to drive multiple different open stack deployments simultaneously and test them. So we actually have ability to run multiple tests on different open stack environments and generate results and compare them. That's kind of more on the QA side, even though it's as part of the rally project. So the second part is the performance. But again, it's performance very kind of narrowly tailored. It's not tailored to individual project. It's tailored of the user experience on a couple of the, I would call, prototypical applications. Again, most, actually all of those applications, I'm aware of right now are cloud scale applications. I mean, they're not enterprise or NFV, they're kind of cloud targeted ones. So that's one, again, it's not gonna stress or get the performance numbers for individual project, nor go through the easy design for individual project good enough, nor have any measure for that. So I'm not even 100% sure of that level of the benchmarking and the performance that would be applicable to that thing because it's kind of very targeted for one role. So it sounds like a useful thing to do. In a useful theme, I just trying to understand how to target that. Yeah, I know, we had one customer that when we were talking to them, they gave us a target that said, okay, I need to be able to set up X number of VMs in a finite period of time because that affects their scalability. In other words, so again, that's why I kind of map it and say performance at some level limits how big you can make things. And we ran into some issues with cinder drivers taking too long. It was actually slowing it down so we had to go work with another partner to help them clean up their cinder driver. So we are, I mean clearly that's an issue that we look at, it's this question of how do you lump them into themes? That's another one. That's a good one. Yeah, that's a good one. So I heard performance, I heard clean up the cruft and I can't remember, what was the third one? Oh, was keeping it up when you need to do continuous integration? Cd continuous integration. Continuous deployment. So are there any other big misses that you think we've got right now? Because I think we're about out of time. So if, oh, please. This morning there was an interesting presentation on backups and sort of data safety. Okay. And it seems to be a little bit of an elephant in the room as much as well. Very often clouds are perceived to be, you know, ephemeral and well, we can just throw away the data. But if you're gonna be running any sort of important application on your cloud. Go ahead and say, I'm gonna run pets on my cloud. That's okay. I mean, you know, I'm just looking at this dashboard here and I can't see it here. I know there's a number of up and coming projects. Where does that fit? So I know that, for example, there's a Cinder backup. So Cinder itself is addressing backups. Is that one? Yeah, I'm not sure about Manila if they're doing anything specific. So that's a good point. We can track those. Yeah, there's a couple of things there. So there's one which is part of the Swift because Swift actually can be configured to be multi kind of site. And actually, you know, you can back up, you know, the ability to go as synchronously to a different area. And as long as your kind of Cinder and Glance images are all, you know, using that as a back end, irrespective of what the actual implementation of the Swift is, then it kind of gives you a little bit of that. But it does not provide you a very clean API to down the user point of view, for example, to do it on the application. You know, you can do it per VM. Sure, you can do it per image. Sure, does it allow you to do kind of consistent snapshot of the application? No. And you can conceptually try to write, you know, heat template to capture that, but there is no plugins for that. Yes. Very good point that was made this morning as well, is that well, you know, I mean, basically having something stable that you can perhaps replay all the time that probably also includes infrastructure level, configuration, you know, your flavors, whatnot. I mean, it seems like it's a bit of a cross-cutting concern, and I think what you just said is that it's well, it's addressed in places, it seems like a bit of a hot spot thing. Yeah, right, exactly. That's a good point, excellent. Okay, so we have four. Good, go. Product. So can I just say to that, the project smorg is trying to address that and trying to pull all of the bits that are your application and drive all of the individual backup bits under that. It sounds like it's trying to do what you want. I'm sure they'd like to hear why they're failing and what they more than need to do. They're actually very responsive too. So smorg. Smorg. Frit, yeah. So smorg aims to drive things like Frieza. You know, it's a top-level orchestration. It doesn't do any backup itself. It just goes and grabs information and remembers where everything is and will take your application apart and find, disrupt all the bits of it and tell you how to back up all the bits individually and then draw it up. Thanks very much, Duncan. So I think we're out of time, but thanks, everyone, for your attention. And as we said, if you've got more feedback, you know, the product working group mailing list is a great place to hang out. Thanks, everybody. Thanks.