 He's the DJ. All right, let's get started. This is contributing to OpenStack doing the dirty jobs. I'm Xin Yang. I'm a senior consultant technologist from Dell EMC, also a core developer in Sender and Manila. In October 2011, I attended my very first OpenStack Summit in Boston. That was the ASSEC Summit. I knew nothing about OpenStack at that time. In the following year, I made my first contribution by submitting a Sender driver to support EMC storage. And I became a core developer in Sender and Manila during the June release. That was 2014. I'm very happy to be here today for my 11th summit and give a presentation with Scott on how to contribute. And I'm Scott DiAngelo, I'm a software engineer at IBM. You can find me in IRC or shoot me an email. Sender core developer worked on the HP Public Cloud for a few years, worked on the healing release. My first summit was in Atlanta in May of 2014. I gave a talk in Tokyo called Contributing 201. And it was geared for the not so new contributor. The idea being, you've done your first patch. You kind of know what you're doing. You're not quite tightly integrated. You're not a core developer. You're sort of what we call the middle class developer. In the time since then, I've become a core developer. And I've been doing this full time. So hopefully some of the experiences that I found on the way, we'll share with you here. So what are the dirty jobs? They're basically jobs that have to be done, but they're not necessarily very fun. People have a nice shiny new feature they want implemented. They've got some really cool thing they want to do in OpenStack. That's not a dirty job. That's a fun job. But there's a lot of work that needs to be done in OpenStack. And it's incredibly important stuff. But it's also the things that tend to get neglected, things like tests, reviews, bugs, mentoring other people. There's a lot of gaps in cross-project areas. And of course, everybody's favorite documentation. So tests, I think the most important, most neglected dirtiest job there are. We all want to write our features. If there's a requirement that you have to have unit tests, you'll do it because you have to get your patch merged. But what we often find is we'll say things like, yeah, we're going to follow on with some functional tests. And those functional tests never get written. So there's lots of areas of testing where someone who wishes to contribute can find plenty of work to do. So in Cinder, we've got functional tests that need doing, active-active high availability. We've got microversion tests, backup replications. We have whole areas of testing that are just looking for a contributor. Talk to the former Keystone PTL. Same thing happens in Keystone LDAP, federated off. There's a completely undocumented and untested feature in Keystone if you're interested in contributing to Keystone. Bug 1635389. Same thing with Neutron. They've got something in their repo under the dev ref for missing infrastructure for testing. So if you're a Neutron contributor, there's a whole list of things for Neutron. If your service is one other than these three, I'm sure you can find ways to contribute to testing in areas that aren't done. Cleaning up and refactoring unit tests. If you run the unit tests and you look hard, you'll often see warnings that are getting ignored. There's definitely areas in most unit tests where things aren't very efficient. So if you have time, you want to look through the unit tests, watch them as they run, time things, just do some code reviews. You can see sometimes things that are outdated that are being used or just general bad practices where things should be mocked out but they're not. And then there's Tempest. We complain about Tempest and our lack of understanding of it, our lack of expertise of it, why it's so hard to get test merged into Tempest. So if you're wishing to contribute in any project, one place you can go is the Tempest test for your project and work hard to understand them when you see failures in Tempest and queries coming up in your IRC channel saying, hey, does anyone have time to look at this failure because it's blocking the gate? That's a great way to contribute. There are some people who really understand Tempest and contribute to it and there are very few. So it's always an area that people can contribute to. You can definitely go to the QA IRC room and ask them if there's anything in your service area they need help in with Tempest tests as well. And become the test leader. So we saw so many gaps in testing in Cinder that I just kind of started the test working group. I just basically started running a meeting once a week, got people to start contributing to an etherpad and basically looked for areas where we could get things going. It helped move things forward a bit. But if your project doesn't already have someone leading the testing efforts and you wish to contribute, that's a great way to get involved. You don't have to be elected. You don't have to have any kind of qualifications if you just step up and raise your hand. I'm sure you'll be welcome if it doesn't already exist. Doing code reviews is a great way to contribute. Anyone can do code reviews. If you have already got a project that you are interested in, just go ahead and do code reviews there. If you do not have anything specific in mind, try to pick an area and become an expert there. Try to find an area that has not got enough attention, such as the documents, the APIs, client, and try to help out there. Help is the doc reviews. The doc team has a very nice document on how to do doc reviews. The first thing to look at is the commit message. Of course, that applies to both doc reviews and code reviews. So check to see whether the description in the commit message clearly describes what the patch is about. Check to see whether there are multiple unrelated changes in a single commit. Check to see if there is a bug number referenced in the commit message for a bug fix or a blueprint for a new feature. Read the content of the doc patch and check the spelling, grammar, the style, the wording, phrasing. Doc team has a lot of writing style guidelines. For example, we should be using capital case when referring to a service name, such as a compute service, and use a lowercase when referring to a project name, such as NOVA. Check to see if the doc patch follows RST conventions, whether it has technical accuracy, and so on. So here are some of the open reviews in OpenStack menus. Take a look and see if you can help with review any of those patches. Help with the code reviews. NOVA has a code review guidelines. Not every project has such a guideline, but some of the information in that document can be applied to other projects as well. Some information are NOVA specific, but others are generic guidelines. For example, it talks about what to look for when you are reviewing changes related to upgrades, such as the RPC API versions, object versions, data schema changes. In projects such as Cinder NOVA that support rolling upgrade, we need to be very careful with data schema changes. So adding a column is fine, but the dropping or altering a column cannot be done easily. A column can only be dropped if it has not been used for at least one release. And the API working group has extensive guidelines that we can follow when reviewing API-related changes. Pay attention to the terms used in the REST APIs, and the naming conventions, and the HTTP response codes, and so on. And check to see if a weather or micro version bump is needed for the patch. In general, if there is a change in the request or response of the REST API, then a micro version bump is needed. When reviewing driver changes, take a look and see if there is a third-party CI for that driver reporting. It must be reporting and need to be reporting successfully. And also check to see if there is a release note, if a release note is needed. So if a patch has upgrade impact or security impact or introduces a new feature or fixes a critical bug, then that is needed. So another neglected area is spec reviews. Oftentimes, spec reviews will carry on from one release to another. So there's no real timing issue there. You can jump in at any point during the release cycle. They take some deep thought. So this is a reason that maybe they get neglected. You have to actually spend some time on the review to understand things. You'll probably have to go off and do some research. So these reviews tend to get neglected. But it's very useful to the team. And it's also very useful to you because it'll help you become more expert at your service or your project. You'll get a lot more deeper insight by actually having to review the spec. So a great area where you can contribute, not an easy way to rack up a review point by getting your plus one on there, but it's definitely something that's needed. And it's always going to be appreciated if you can put your input into a spec review. So when reviewing documents, we need to follow the doc review guidelines and make sure the documents look perfect. When reviewing code, the most important thing is to make sure that the code is functional and efficient. We should still look for typos, white spaces, missing period, and other styling issues, but just don't overdo it. If a patch has already been reviewed many times, it has already got a plus two. And if you found a missing period in the comments, then that's the only problem you found in this case. You can still go ahead and add your review comment, but just don't give an active vote. It's good to make the code look nice and neat, but too much nitpicking will slow down the progress. Reviewing a large complex patch is the type of dirty job that is always needed. Test the patch if you can. And add a review comment to point out a problem that you found out during testing, or just add a comment saying that I tested it, it worked. That's a very powerful review comment. Of course, this is very time consuming. You could be spending hours testing this one patch, which only gives you one point on Stakelytics, but this review carries more weight than a quick review of a simple patch. The Stakelytics is great in showing the quantities of the reviews, but it does not really capture the quality of the reviews. The quality of the reviews is more important than the quantity of the reviews. When doing a co-review, read other people's review comments. That's a great way to learn how to do co-reviews. Also, if you join a review late, try to read earlier comments so that you won't give the same comment that has already been given earlier by others. So bugs, there's always bugs. There's more bugs than we'll ever get to. So it's a great area where you can contribute. One is just the starting point. People file bugs all the time. You can help to confirm the new bugs. First thing you can do is check to make sure there's enough information there for you to reproduce the bug if it's reproducible. If it's not, please ask the person to update the bug. If you can reproduce it, change the status to confirmed. If the bug has security implications, you can set that flag. There's often official tags for your project. I know for Cinder, if it has to do with a certain driver, there's tags for each driver. Almost all the projects are broken up into different areas where you can tag them. So all this stuff helps, it just helps people when they're looking for bugs to fix or they're looking for things to review. They can very quickly look through things. Prioritizing bugs is usually the job of designated bug supervisors, but you can just become a bug supervisor. It depends on the project, but in many cases, it's just a sign up thing. So whether a bug is important or not is something that people will use when they do their filters, when they wanna look for bugs to fix or reviews, they're looking for the high priority bugs. You can help with all of this. And then there's sort of an ongoing thing. Sometimes a bug will pop up, it'll get fixed in an hour or a day, and then get reviewed and get merged in. That's a certain class of bugs. Then there's all the rest of them, and if you go into any project, you'll see some bugs that have been languishing in there for months and years. So one thing you can do is review the state of bugs, make sure that things that have been sitting there for a while, if they're a high priority bug that's been around for a couple of years, you can start pinging people and say, what do we need to do with this? Because it's obviously not getting any attention. If it says it's in progress and there's no progress, you can start pinging people and say, find out if there's somebody who it's been assigned to, if they're even still around, if they're working on it. Unassigned bugs could use an assignee, maybe it's you. Incomplete bugs, these are the bugs that you've sent back to the person who filed the bug and said, we need more information here. But if it's a three month old bug that's incomplete, you probably just close it and say, this person's not responding anymore. Another thing you can do to help is adding information. So if you're reproducing the bug or you've got it up on your system, you get different information that might help to solve the bug. You can go ahead and put that in there. Obviously, one important thing is can you fix this bug? As I said, the amount of bugs grows and grows. So anything you can do to help fix even low priority bugs helps get the bug backlog and then verifying the fix. Bugs get fixed, things get reviewed. It kind of plays into what Jing said about reviews. Sometimes the person will put up a bug fix and then when you try it, it won't work on your system. It won't work on your distro. So verifying the fix, or more importantly, saying this doesn't fix the bug for me and explaining why it can also help. Mentors are always needed and being a mentor is a great way to contribute. Here's a wiki that shows all the mentoring programs in OpenStack. The first one is the Outreach Mentoring. Outreach is a program that helps people from underrepresented groups in open source get involved. OpenStack Foundation has joined the outreach program to encourage more women and other underrepresented groups to contribute more in OpenStack. This is like an intense internship over a three-month period of time. The mentor should help the mentee and identify a task that can be accomplished in three months and help the mentee to get it done. Upstream Institute is a two-day class for beginners that is held onsite before the summit starts. It provides hands-on trainings for newcomers to learn how to contribute to OpenStack. There are regularly held RSC meetings for this training so you can attend those meetings and provide feedback there. They also, you can help review the training materials and you can provide assistance during the training, during the OpenStack Upstream Institute RSC channel and see what you can do to help. Anyone can help. Lightweight Mentoring, this is a mentoring program sponsored by women of OpenStack. It was started before the Austin Summit. People who are interested in being a mentor mentee sign up for the roles and a match will be made between them. And the mentor should work with the mentee to identify a goal. In my case, my mentee said he wanted to learn how to make contributions so that was straightforward. The type of mentoring can be either technical or career depending on what the mentee needs. Speed Mentoring, this is a session that happened earlier on Monday, lunchtime. It used to be held at seven o'clock in the morning during previous sessions, previous summits. So this is kind of like speed dating away. A mentor would talk to a group of mentees at a table for a period of time and then rotates to the next table. This is also sponsored by women of OpenStack. I joined this session during the previous summits and I got contacted after summit by a few people that I talked to during the speed mentoring. Although they did not need to find a mentor themselves, they asked me whether I am willing to be a mentor for their coworkers and I said yes. So this is a great way to help newcomers as well. So answering questions is another great way to contribute. If you hang out in any IRC channel, you'll see many people come in with questions. They're new, they need some help with a specific problem. Sometimes those questions go unanswered. So anytime you can spend time there and anytime you can contribute, that's a huge help. There's several channels for newcomers. There's several channels for development questions, OpenStack 101, OpenStack Dev. And then of course there's your specific project channel where hopefully you have some expertise and you might be able to help. The mailing list is another place. I remember my first mailing list post was a little intimidating. This is going out to everybody who's subscribed into the OpenStack Dev mailing list. But if you can offer help or even an opinion, if you have something you can contribute, that's always a great way to help. And then there's ask.openstack.org, a great place for you to ask questions, but if you go there and you can answer questions, you're gonna be contributing. Then there's the cross-project gap. So we all live in little silos. We have our projects. We learn how to contribute to our project. We hang out there. But there are many projects that interact with other teams. Just a few of the interactions that take place between say Nova Cinder, Neutron and Nova. Horizon interacts with all projects. Manila and Neutron. So these are areas that basically fall through the gaps. I don't know of any project that has the expertise between itself and another project that they would like. The communication is often missing. If there's an area of interest to you because you are a network person who works on Cinder or Cinder person who knows a little bit about Nova or something like that, you can always contribute in these spaces. So look for these gaps because it can be anything from an area that's neglected to an area that has zero attention. We tend to get into silos and this is a great way for you to contribute in a way that's gonna be very welcome. So how do you do this? Go to a meeting. It can always be valuable to go to another team's meetings because you're gonna see that they interact in different ways. They organize in different ways. But often you can find questions asked about perhaps your project where there's no knowledge available. You could also find ways you can contribute. For example, Nova has a tag on bugs called Volumes and they talk about it almost every week but if there's nobody from Cinder there, then there's nobody to help answer questions on that. IRC channels. You can go to different teams IRC channels. Helping with the bugs, like I said, there's tags often so you can see if there's a tag for networking in your Manila projects or wherever you have a cross-project interaction. And then you can look for cross-project liaisons. There are designated liaisons between projects. A while back there wasn't a Cinder liaison to Nova so I joined in there, I had some interest and I was able to quickly contribute because it was just an empty space that needed filling. Then there are cross-project projects so there are projects that by definition encompass various services or all the services and if you attend some of these you'll find they're really, really sparsely populated. They need help almost every single one of them. The API working group is great. You can learn about standards of APIs. Every service has an API. All of our APIs are all over the place with regards to how things are implemented and one thing that would probably benefit OpenStack as a whole is to get towards a cohesive API. So the API working group tends to look at that as their mission which is to sort of set standards, figure out best practices and make that known but they can't make it known if you don't pay attention so if you're a member of a team or you want to contribute to your team, participate in the API working group, go to the meetings, read the docs, do reviews. I go to meetings, there's usually three or four people there so there's a lot of services that aren't even getting represented. OpenStack clients, another one, we're moving from individual clients for different services like Cinder, Nova, Glance, et cetera to the OpenStack client. We're not there yet but there's plenty of room to contribute there. Oslo, the library that's shared, QA always needs help. Infrastructure, security, RethStack, all our areas that cross the boundaries of different services. So if you have an interest there, you're gonna be welcome. Documentations are important. Everyone should help with the documentation. You can help write documents in OpenStack menus. There are many types of documents in OpenStack menus such as the admin guide, user guide, CLI guide, Insul guide and many, many more. Read the documents and see if you can help. If you know a new feature was just added in a project, check to see if there's any documentation for that. You can also search for OpenBox with the dark impact flags. So here we search for dark impact flag in Cinderbox. The lot of bugs showing up and they're still in the new status. So take a look of the list and see if you can verify them, see if there are still bugs and see if you can help fixing any of them. Help with the API docs, see if there's any missing docs in the APIs. And also you can search for a box with the API ref tag. So here we search by API ref in Cinderbox. So there are some OpenBox there. Take a look and see if you can help with any of them. Here I'm showing you a way to look for a missing doc. This is the rest API version history in Manila. It shows the other API versions and also what the changes happened with each version. I highlighted 2.31, that's convert consistency groups to shell groups. Now let's take a look at the API ref doc in Manila. So we see there are documents for consistency groups, but we don't see any documents on shell groups. So here's a missing doc. The documents on consistency groups should be converted to documents on shell groups. So one trick I've learned is to actually use the debug tool in the clients. You can actually see the API in action by running Cinder with debug, Nova, Neutron, whichever service you have. If you need a token to do a curl command, you can use open stack token issue. And you can rerun that command and get the output. You can look at the body and the rest API output and you can verify that it is in accord with the API docs. When people have done this, they find that they're usually very inaccurate. So looking for something to do, you can help with those docs. So in projects such as Cinder, after a new feature has been introduced, the driver maintainers need to implement those features in the drivers. So writing a document to explain to the developers how to implement a feature in the driver will be very, very helpful. This is a picture of the documentation and the I-18N team taking at the PDG. Join them and help with the documentation. So we just wanna acknowledge some of our artists that we used for our slides. And then if there's any questions, we can answer them. This is being recorded so you can use the microphones. There's not really a go-to list. Early on, I pointed out that in their dev ref, Neutron has a list. People kind of put things in different places. I think really if you just go to IRC for the channel of your service and just say, hey, I wanna help, is there an area that needs work? Someone will certainly speak up and say, this is this thing that needs doing, nobody's doing it. We need some tests written here or we need this bug fixed or various things. You can always ask, I think people will be happy to hear you step up. Just a simple question, is the Horan use the API to control every project? I believe they use the client, the Horan use the client, not directly using this API. Other questions? All right, thank you.