 Thank you, everyone. Thank you for joining Megan, myself and Rocky to discuss how to contribute to OpenStack as a user. So before we start, this session was proposed by the product work group and so there's more information about the team itself and we're going to discuss in a little bit as well. But the intention here is to help people understand what are the different working groups and communities within the OpenStack ecosystem that you can participate in, even if you are not a developer from a services perspective. But before we start, I have two quick questions. How many of you are developers? You already contribute development-wise to OpenStack. Okay, so we have one person in here. And how many of you would say that you're relatively new to OpenStack? New as in someone who's still learning what the project is, the different services. So how burst are you in the OpenStack? It's where it is today with services, capabilities, etc. Okay, so I would say that's fair. So probably like two and a half? Yeah, exactly. Okay, so good. And I'm glad that that seems to be the case. The entire crowd is not new because one of the things that we were definitely focused on was just because it's contributing as a user doesn't mean that people aren't experiencing OpenStack. What we want to do is we want to take your experience in OpenStack as potentially an operator, as a business executive, and apply that to the community to be able to bring a perspective into the community that's needed to ensure further adoption and user experience, if you will, of the platform itself. Megan, do you want to introduce yourself, by the way? Hi, I'm Megan Rosetti, and I'm with Walmart, and I've been a part of OpenStack since April of 2014. And it is just continuing to grow and expand. It's great. Absolutely. So why do we propose a session? So the interesting thing is here, you know, OpenStack has tremendous velocity, and we have a really big developer ecosystem, you know, upwards of 4500 plus developers in the community. The other interesting fact is there's over 31,000 members registered to the foundation. And so out of 5,000 developers, there's a significant amount of people that aren't really developing, but yet they're participating in the community, and that's what we want to share, is how to kind of continue that aspect and how to get involved further. The other interesting point, and the colors really are not showing up well here, is the fact that this slide at the top shows the distribution of people that went to Vancouver. So how do people classify themselves? And as you can see, you know, we have 30% developers, 6% operators, 10% management, but it's a good mix of people with different backgrounds and skill sets coming together at every summit. So in this session, what we're going to do is we're going to talk about the user committee. Afterwards, we're going to talk about the various working groups that are under the user committee management, and from there we're going to talk about additional ways, you know, outside of even working groups, for example, that you can contribute to with an OpenStack. And then lastly, we'll kind of end with, you know, what are some of the tools of the trade? So how do you set up a development environment? What are some common gate commands that you might need to know even if you're doing documentation, for example? So from that perspective, let's start with user committee. So user committee consists of three members, which are generally OpenStack users or operators. And so this actually slide is out of date as of yesterday now, actually. So generally, there's one board appointed user committee member, there's one technical committee appointed member, and one additional nominated member. And so yesterday, that used to be Tim Bell, John Polo from MIT, and Subu. And as of today, the user committee is Subu, John, and Shela Seibi from Comcast was just recently added to the user committee as well. And so as new working groups form, like if there's an area of interest that you have or that you serve or market that you serve that isn't represented as we go through these slides, definitely bring it to the attention of the user committee and they'll help you kind of get started in building a community around your area of expertise or interest. So as I mentioned, the user committee is kind of an umbrella governance model, if you will, and there's various teams that work underneath there. There's two main ways that working groups are formed within OpenStack. There's teams that we consider focused on user requirements for market segments, and this is the green side of this chart here. Those teams are generally longer lasting, so they kind of continuously bring new requirements into OpenStack, and so they're kind of considered almost like ongoing working groups. And the other side is working teams which are basically brought together for a specific interest. So for example, as we need to solve logging in OpenStack, there's a team brought together to figure out how do we attack that, but that's a point problem and once that problem is solved, that team doesn't really have to continuously exist unless there's new things uncovered that have to be addressed from that perspective. And then the last piece is the product work group, which is again, as I said, what we represent. And the product work group is actually working to kind of take the different working groups as they come up with outcomes of, hey, from an enterprise user perspective, it would be nice if OpenStack did this. What we're doing from a product work group is capturing what this is and then helping making sure that the development teams are aware of that requirement from that market segment going forward. So with that, what we want to do next is kind of, it's a lot of slides, we're not going to spend too much time on each working group, but we want to at least provide a high level overview of what the different working groups are today. So as you see this list and we go through it, think about if there's any topic here that really resonates with you or that you're passionate about, and what we want to do is we'll help you get involved and there'll be links on all these slides, and the slides will be published later. So even if you don't catch the URL right now, you can always go back, refer to the material and join in later. So that, Meg? Thank you. All right, so I'm just going to spend a couple of seconds, literally on each slide. I want to run you through what the current working groups are. And as Shamal said earlier, there is links on each slide to both the Wiki page and the mailing list. So see what you're interested in. Definitely check out the Wiki page. It has meeting notes. It has more information, not just the mission statement, but also what they're working on. It also has meeting times, information, all of that. All right, so we're going to run through these pretty quickly. We have the Enterprise Working Group. The Enterprise Working Group is, did that go? I touch it. We have technical difficulties. The Enterprise Working Group, the mission is Enterprise Adoption. So with the Enterprise Working Group, there are several sub-teams to that. That'll be fine. All right, so just really quick to let you know that for the Enterprise Working Groups, the sub-teams are the business and marketing, the catalympics, deployments, and then fantastic. Thank you for coming. And then the Enterprise ISV Interop Team. We have the Telco Working Group, which focuses on running telecommunication services on OpenStack. The Application Ecosystem Work Group, which handles running applications and growing those applications globally. Large deployments, focusing on large deployments. The HPC, which is high-performance computing, using OpenStack. Public cloud providers. I think that's straightforward, but let me know if you have questions. You have the Logging Working Group as well. Logging certainly has had a lot of questions. Many companies find the different needs and different resources. And then we also have the OSOps project, tools and monitoring working group as well. And the API working group. And finally, the ops tags. All right. And we're going to jump back over to the Product Working Group. And by the way, just as you know, we went through the work groups really fast. As Megan mentioned, a lot of us are involved in the Enterprise Work Group as well. So if you have, if that's an area you're interested in, any three of us could probably talk to you about that as well. Rocky is also very involved with logging. So from that perspective, and turn on. Do you want to turn on your? Providers in logging. Come see me. Yeah. Large groups. So yeah. So we have like probably three or four working groups here represented just between us three. So from our work, from a Product Working Group perspective, as I mentioned before, what we're really trying to do is, as these different working groups come up with concepts and features, enhancements, you know, bugs, et cetera, that have to be resolved in OpenStack to serve their needs. The Product Working Group is trying to aggregate all of those different requirements from different teams and basically share them back with the development teams. So what we're trying to do is also a lot of these things, like for example, from Enterprise Working Group, we've got rolling upgrades as a requirement that we're currently working on. And so these things usually require cross-project coordination. There are generally multiple features in each project. So they're multi-release in nature. So these are very complex things that, you know, from a very simple perspective, start off with one sentence, which is, as an Enterprise user, I want to be able to do rolling upgrades for my OpenStack services. So that one sentence gets expanded into, you know, tens and twenty, you know, blueprints per project, effectively. So the coordination of that is something else we do. And the last thing we do is we actually publish a multi-release OpenStack roadmap. So we actually work with the project teams and we kind of talk to the project team leads and ask them, you know, so what did you deliver in this current release of OpenStack? Where are you going next? And then we know that you can't really give us, you know, indications of what's going to happen next, because as an open source community, OpenStack's release vehicle is every six months. So until the next release cycle opens up, project teams can't really sit down and come up with, you know, specific blueprints and specs they'll be pursuing per release. But most teams have an idea of, you know, as a project team, we're going to continue focusing on scalability or resiliency of a service. So using that data, we hope to make, you know, as OpenStack users and operators a little bit more insight into directionally what things are going. And by the way, as of today, the OpenStack roadmap page, which is opensack.org slash software slash roadmap, just got updated with the latest copy of this multi-release roadmap. And one thing with the working groups, all the slides that we ran through before, those tend to feed into the product work group. So it's a very good place to really dive into and use that information to bubble up where it needs to be. And also, hopefully, if you have something you want to do within that particular group, you can get help from the product work group and help get some focus on it. Get it incorporated into user stories and then get it propagated back out again. Exactly. And so from a, you know, as we just showed earlier from the user community perspective, we're kind of, you know, trying to funnel the different working groups requirements into the development cycle. So from that perspective, I encourage you, from a market perspective, participate in those working groups and eventually those requirements will come in through the product work group as well. And then likewise, we have our user stories publicly available on an opensack group repository. Go in there periodically. We have like four prioritized stories we're pursuing right now, but there's 20 other ones in the backlog. And if there's something in there that resonates with you already, just, you know, chime in, drop us an email or something and say, this applies to me. Just so we can understand the demand for various stories and whatnot. You can put yourself in there, but your user story seems to fit within the whole context of the product working group. You can actually submit it and we'll go through and help you through that process. Awesome. So Rocky, with that, you're actually up next on how else I could contribute. Ah! Well, there's lots of ways. Really quick. There are docs. Generally, you're getting started. You're reading the docs. You submit a bug. That is testing the docs and the guides. You can test the software itself. We're always looking for new tests to go into Tempest and there probably will be a couple more tests. There's also Raleigh and a few other test places. Revstack, which is for vendor testing and non-test cloud, so for production clouds and test clouds outside of out of the continuous integration stack. There is training. I think we saw in the keynote that there's going to be the certified open stack admin. We need really we need a lot of help on training. Training docs. We're doing labs and we're doing a process of generating what is the whole session and what are the key points to certify someone for admin and other aspects of testing. We need help on translations. Mostly with the docs, but also with error messages and other messages that get posted through the system. We need people to come to the ops summit and provide either help provide insight into stuff that they're doing that works for them and to ask for help for things that aren't working. There's a new process for working within the projects. It really one of the hardest things about open stack is there's just so much information that it's hard to keep track of everything and if you don't see it you end up not following the rules and it's complicated. So there are three different ways now to submit features to be included. Coded features for open stack there is the blueprint process that has been reduced to small minor features but that's the simplest method. There is the specification that goes through gets reviewed by the entire team and when the information is considered good enough and the questions have been answered then you go off and code that's for larger pieces of new features and then there are now RFEs in some of the projects which you use a bug in Launchpad to file a request for an enhancement or a feature you describe what you want what you need and feedback goes through the bug cycle as opposed to the blueprint or the spec. So three different ways don't you just love it and if you want to just start doing reviews product workgroup telco workgroup we've got user stories we don't have the link for that up here but you can start reviewing those guys and it literally doesn't take anything but the will to read and comment and a couple of tools so we're on the tools now this is how you get started join the foundation the website is right here and you can read how to contribute join a mailing list mailing list will give you context that's where a lot of the discussions go on and they're usually identified per project if you have a specific focus in brackets on the subject line so you can ignore anything that's not of interest to you go to the IRC meetings it's good if you can go out and hang out in the IRC but during meeting times you know that there will be discussions that will give you more information you can actually set up an environment to contribute code but and documentation also requires the same setup for viewing all you need is open stack member a foundation member a launchpad ID and you're ready to review that's all you need that's the first two steps in the join and the how to contribute and it's the easy part of it to get more setup so you can start making comments and adding your voice virtually today it's that simple and we'll help you if you need it to get to that point and here it is you can see the launchpad and the review and that again is divided up by projects and this is where we go to ah this is actually a page that I hadn't seen before but this is the process of doing a review you go to the site that has the reviews linked to them you find one you want to read you click on it you read the message which is a summary and then you can actually read the individual patch by clicking on it further down on the page we should have an example of the page here but we don't we'll be happy to walk you through it and then you can vote as to whether you think this is good enough whether it has problems and you will comment on what those problems are you could also vote zero that means you've read it you might have made comments in a way whether it's good enough or not but you'd have comments to make and that's perfectly valid and this is where Shamal takes over again I can do this but I'm QA so any machine I work on will break for me and so even though I have this set up on my machine it won't work so this is here more for again your reference so if you download it or you can actually view this and again a lot of this is actually covered in the how to contribute link that we had earlier so what we're walking through here though is just some simple commands and commonly used commands obviously there's more enhanced and advanced get workflows but for the most part what you want to do is you want to be able to clone the repository of where the documentation is or the code is after you do that piece you want to be able to check out that branch so you can make your own modifications to it so this is basically your local copy once you've made the edits that you want to make you can actually do if you're adding a new file you have to do a good add otherwise if you're modifying existing files you can just move on to git commit what the commit does is it takes your local changes and gets them ready along with the commit message where we're talking about the summary to be merged if you will or submit it for a review and once the last command here is you do a git review and that actually submits it to open stack through the workflow and basically after this your contribution doc, code, etc. is available for others to come in on review.opensack.org and provide feedback and then once you get someone who is considered what they call a core reviewer I mean they have the power to actually do the approval whereas the other when we were talking about reviews earlier we did a plus one minus one as an option that's basically you're giving your input into what decision should be made regarding the submission but really you need a plus two which is go ahead and it's approved to merge or a minus two would equal that no this is not ready to be merged so basically once a core reviewer comes in only core reviewers have the capability of doing plus two or minus two but once that action is taken your code and your patch set is merged after that more or less the one thing to note is that if you see a minus two there are a couple reasons for a minus two one reason for a minus two is that the time getting new code has ended during a release cycle and what that means is you resubmit it for the next cycle that's usually announced on the mailing list another good reason to join the mailing list the other reason for a minus two often is that the developer the core reviewers think that there needs to be much more discussion possibly a change in implementation or some other thing a bit more major that actually requires more interaction with people than just going through with the current flow or actually there's a third somebody else already did it yep absolutely so in this last piece here is just we covered the basic get workflow here what we're doing here the community as Megan showed she mentioned the meeting times all the community meetings happen on IRC so to participate in those meetings you can log on and have a nick you can use temporarily but most people end up registering IRC nick so that way they can validate that it is them who's speaking and so once you start participating in working groups even a lot of working groups use IRC as well what you want to do is go on and so we just provide a brief summary of the steps needed to do that piece as well just to hopefully save you some time from having to look it up yourself but again this is much more for reference material and as you see it's nick as a nick name not nick as in network that's funny okay so now that we've covered the content again hopefully this video will definitely be available and hopefully we'll try making the slides available as well I guess what I wanted to kind of get was we got a good population here so how many of you are operators of OpenStack okay good so we got about four operators we have one contributor and how many of you actually are I guess like developing applications on top of OpenStack so how many of you are actually consuming OpenStack clouds okay so yeah that's awesome I'm surprised we got that much like SDK and application developers here because that is a really big push from the working group perspective that we need more people that are developing applications that consume OpenStack clouds to be able to give feedback on SDKs as well so please if you have the cycles there's the application ecosystem workgroup that was there please participate in that for those of you that were operators definitely as we talked about definitely go to the ops summit if you can attend as well as join the operator mailing list and participate in that manner and actually if you're an operator and you come across a problem that you don't know how to solve you can do mailing list or you can go straight out onto the IRC and ask your question there's almost always somebody out there who can answer or at least help you along the way yep and they're really friendly absolutely so we touch based on operators we touch based on developers how many of you are considering whether if you're representing a market segment does OpenStack apply to my industry my needs my business segment if you will do we have any like business managers I guess in here or product managers program managers project managers I saw a hand yeah okay so it sounds like the biggest audience in here is the application developers so I think we have about how many of you don't know what you want to do or where you want to go but you're here to find out some information wow everybody's we got someone thank you so since we've completed the material we still have like 10 minutes does anyone have like any questions or any material that we should revisit before we get into the questions really quickly I was going to just go back through the slides in case people want to write down any of the working group information while people are asking questions so I'm just going to run through those so as we're going through slides was there any topic that you were expecting to be covered in the session that we did not address yet so we have time so we can definitely talk about additional topics as well okay how many of you saw even in a second per page that we went through how many of you have seen something here that interests you from a working group perspective or a topic perspective okay good well actually can we get a just can you comment on what you find interesting that seems to be your passion or whatever cool so there are actually two groups on logging and APIs there is a developer group on trying to standardize APIs and develop API guidelines there is a box section specifically on API guidelines and I can give you a link to that in the future but if you go to docs I'll have to post it up later this is a page where all of the guidelines have been published to the open stack wiki well to the open stack site not the wiki okay next we're actually starting it here okay so the public no no no no no this is for anyone and everyone who is a public cloud provider to come together and work through issues and come up with solutions yes and that's exactly one of the the public cloud providers have certain requirements and needs that are very different from the enterprise world or the hbc world and until recently the large large system group kind of covered it but we think that there are differences between that too so yet another working group and that is a perfect example of open stack is continuously growing and evolving so it's a perfect example of as the community is growing another need that has come out of that and how that was established and actually it's not established yet we're going to establish it talk to me and we'll get it together yes let's set one up and we'll make sure it happens and we'll either post a sticky on the page or something or we'll certainly tweet about it and we'll see how else we can get it publicized there was one gentleman back there so hbc is a mailing list so right now they don't have enough of a quorum where they've set up regular meetings yet so right now they just have a mailing list but yeah I think you know there's at least a few people I can connect you with that would be really interested and if you were interested in building a team around it they'd be interested yeah yeah exactly I'll connect you with the people the other thing with hbc is there is usually in the ops summit and mid cycles there are there's usually at least one meeting about hbc and so if you haven't looked at the ops tracks take a look at the ops tracks and you can just go and sit in on these things you don't have to know anything you just sit and listen and because they don't do regular team meeting by the way that's why on this one there's an etherpad link because they've collected all of their materials in the etherpad so that would be a good way to catch up perfect rfv rfv process is it was literally put together because there were some things that weren't as heavy as as a whole new approach to something and they wanted to make it more available to people who weren't developers and so you go out and you say this is what I want it should do this and this and this and you don't have to put in alternatives and you can say it doesn't exist yet and just this is what I need and so it's really a short little requirements document of this is what I need and I think that's probably one of the key differences so like right now there's specs blueprints, bugs and rfvs and the biggest difference between them is as Rocky mentioned earlier blueprints are probably much more tactical smaller increments if you will a spec is delivering multiple possibly blueprints to kind of realize and rfv is something where as an operator you could file a bug but it's not technically a bug it's an enhancement to extend the service in a way that it isn't designed to operate right now so an rfv has no notion that you have to volunteer to develop what you're recommending with a spec or the general principle is if you submit a blueprint you will have some resources development-wise that will be willing to work on delivering whatever you submitted so there's a decouplement of just being able to request the enhancement through rfvs and not necessarily you can still volunteer and help design and develop it but that isn't a requirement whereas blueprint specs that's generally considered informal requirements of that process generally generally there's a little bit of discussion on it and so you should if you have something like an rfv or a blueprint one of the things you can do when you've got it together go out to the IRC channel of that project and say hey guys can you take a look at this and get a discussion going on the IRC or say can we talk about it in the weekly meeting once and especially if you've got code already and it's an rfv type of thing put it on the agenda of the meeting for the project and be ready to discuss it and tell them why you think it's necessary and that you've got it all coded up and could you take a look at it so we're obviously a community here right like it's an open source community so we've covered a bunch of ways that we brainstormed and came up with as far as how to contribute as a user I'm sure all of you contribute in some manner as well so if there's something that we didn't cover here like please feel free to speak up and let people know about some other ways that they can participate yes so define project for a second are you talking about a new group that can discuss about a specific area of open stack or a market need or are you talking about project as in a new service within that becomes available as okay so do you yes so the way that would work is independent and this is more about working group and kind of bringing to the people that have similar interests to discuss topics and make actionable improvements in those areas for your specific question what you would use is there's actually another link on the wiki for open stack on how do you create a project overall how do you create a repository and so that's a completely different process and the way that works generally is to become an open stack project especially with big tent you have to use open stack infrastructure services you have to like the review process that is applied to your project so generally what you would do is you would go in you would create a repository through that process once you create the repository you would put in a request to create a new review team you would specify who are the core reviewers as I mentioned earlier but then you would also go to the TC eventually and let them know that I officially want to participate as an open stack project and they will probably most likely because of big tent you know allow you to move forward but yes that process is completely decoupled from this process but it is very well made on the wiki page for open stack as well but also if you have an idea for a new project and you just want to get it out there and you have some bays for it advertise it on the mailing list invite people to come up set up an IRC channel specifically to talk about it and set up a weekly or every other weekly meeting that is a more formal IRC location to talk about specific agenda items you you would apply for the IRC channel through Infra so you just go to open stack dash Infra and say I need an IRC channel you go to their IRC channel and say I need an IRC channel for this new project absolutely yeah this is great I mean I plus wanted both of those so basically it's about you know becoming a part of the community and showing that you know you're willing to participate in discussions around topics socializing and letting people participate before you do what I told you what I gave you was a tactical instruction on how you create it what they're giving you is how you succeed in getting it accepted as well and the other reason to do these sorts of things is there are lots of projects out there right now and you don't know whether somebody is actually already doing something similar or taking a different tack or a project has decided they're going to incorporate something in a spec somewhere and so getting to know the area that's closest to the project that you want to start and making making sure that there is an awareness of what you want to try and letting them tell you whether somebody else is already doing it or if they want it inside of another project or they think it belongs separate those sorts of things get you involved in the community and they start recognizing you as a contributor so we are at time I would like to thank everybody for certainly coming and listening to us talk we will be here we'll be outside for a few minutes so if there are any additional questions I also want to remind everybody that through the app there is a feedback button and we definitely want to hear your feedback if there's anything that you think we should add in the future kind of where you would like to see this talk grow thank you very much for your time