 Good afternoon, everyone. Open stackers, and now you will be contributors. Hopefully, if you are here, you want to be a contributor to OpenStack, or you already are a contributor. I see a few of you in the room. Just a show of hands if I bring it up. I want to see, do we have any current contributors in the room? Don't be shy. Raise your hands. OK, we have a few. We're going to use your knowledge and skills. If people in the audience have questions later, hopefully they can ask you. We would love to have you help us out. We are a community. As a community, we welcome everyone. Right now, I'm going to introduce myself. I'm Angela Streeter. I work at Rackspace. I'm a cloud technology instructor. I travel around the world teaching people about OpenStack. And I'm very passionate about OpenStack. Our team is very passionate about it. And we are excited to be here and excited to have you here. Right now, I want to introduce you to my other contributors. Hi, everyone. My name is Agnes Sigler, and I work at Rackspace. I am a principal architect on the Private Cloud Solutions team. And I am here because I want to learn how to become an OpenStack contributor. Hello, everyone. I'm Etcher Seti. I've been working on OpenStack for the past two years. I'm a core contributor on Glance, the images services of OpenStack. And I've also recently started contributing to Trove. OK, so briefly, we're just going to say, what is OpenStack? If you went to the keynote this morning, you heard, you know, it is piece of software. It's a cloud operating system. It's more than that. It's a community. It's an ecosystem of people. And we, as a community, all are contributing to this project. So if you are here today, even if you are not contributing to the code yet, and hopefully by the end of this or by the end of the day, you will be, you are contributing. You're contributing by being in the discussions, by using this in your company or for your own personal use, maybe a public cloud account. So welcome. And hopefully you will learn a lot about what really OpenStack is over the next several days. So why would you contribute? Why? In the keynote, they talked about the importance of this. But obviously, we need lots of different kinds of contributors, right? We need the people here. We need the people here to listen to what we have to say, to find out what this software is and what it can do for you, what it can do for your business. But if you're here, you can become a part of this huge community, this ecosystem. There are scientists. There's corporations. It's a huge community, a huge amount of people. Also, as technical people, if you are one of those people in the audience, you can grow your expertise in something that we think is, it's a big thing. We think that this is the next big thing, right? You can work with some really great people, obviously. Lots of great people here. There's lots of people out there, lots of companies out there looking for people with knowledge about OpenStack. So if you're here, also, like I said, I'm one of the Rackspace trainers. So if you're interested in learning more about OpenStack later after the summit, you may go to rackspacetraining.com and sign up for one of our classes and bring your expertise up. So learn some new skills. And also, if you become a contributor, you also get a pass to the next summit in Paris. So join us. And as the keynote said, join the Rebel Alliance to help build a planet-scale cloud, right? So you want to contribute. That's great. I hope not just because you want a free pass to Paris. I know I do. If you contribute, you will join a community of a lot of people. So far, there have been over 2,000 developers contributing to OpenStack community. That's over 76,000 commits, lots of email messages. If you are contributing, please be sure to, or if you want to contribute, please be sure to sign up for the mailing list. So who can contribute? Everybody in this room can contribute. Even if you don't know how to write code, that's not a problem because developers is just one part of the contribution. Obviously, programmers can contribute code. Then that code needs to be tested. And for that, obviously, they use testers and test systems. And the testers also break code. And then the developers have to fix their code again, and they contribute. And after all the great features are developed, the documentation writers documented. Documentation community is really awesome. They are really passionate about what they do. And they are there to help you out as well as new contributors. This is the first time that operators are more actively involved in the OpenStack summit. And that's great because developers can't run cloud by themselves. They need help. Security people need to make sure that the cloud is secure. But in addition to all of those people, there is still more to do. If you speak another language, translate the OpenStack. Translate the documentation, the messages, the user interface. All of that needs translating. OpenStack also needs gardeners. Those are the people that increase comments in code, make the code look better, reduce pilot violations, increase code coverage. And also, you can be a reviewer. So reviewers look at the code patches and make comments on them. Now, this doesn't mean that you still need to read code. These reviewers can review documentation and suggest improvements. What does it take to contribute? Well, first, you need to find something to contribute. As I mentioned earlier, you can test and report issues. You can try to improve OpenStack security. Documentation. Documentation needs a lot of work. It changes all the time. And it takes a lot of manpower to keep it up to date. If you are a UI person, you can work on the design for the OpenStack site or for horizon. Developers. If you're a developer, there should be a lot of areas for you to contribute, mainly code. So I hope my fellow stackers, Agnes and Angela, have convinced you why you should contribute to OpenStack and what are the different ways you can contribute to OpenStack. So I'm a developer. And here I am to show you how you can actually go about doing this. So you're convinced we should do it? Let's see how it's to be done. So these steps are to be followed up only once. So every open source project has some setup where you should establish yourself as, hey, I'm going to be a contributor to this open source project. And these are the steps for OpenStack. I'm going to have a demo later, but not of this component. So all of you have handouts with these steps listed. You need a couple of accounts set up. One is Launchpad. So a lot of open source projects use Launchpad for their process management. Like example, you want to file bugs related to your project. You want to have blueprints for your new features. So all that tracking is done using Launchpad. So you need your Launchpad account. So Launchpad also connects to get it. So get it is a review management tool. So say you have a new documentation change. You have a new code change. And you want to push it up so people can review it and have comments on that. So OpenStack uses get it for that purpose. So once you've created your Launchpad account, it gets linked to your get it account as well. Two, join the OpenStack Foundation. So there is a booth upstairs where you can go sign up for the OpenStack Foundation. You can do it online. Here's the link just to establish you're part of these OpenStack community. The third component is the CLA, the Contributors License Agreement. So there are two types of CLAs. One is an individual CLA, so which each and every one of you should do. And the second is the company CLA. So the company CLA is to establish that you're a member of this certain company to say that every patch I'm contributing is on behalf of this particular company. So you see all these statistics saying, hey, X company is the top contributor to OpenStack. And this is how they know which company you belong to by signing the company CLA. And then the final is make sure you have GitHub account. So I'm sorry, whether you're technical or non-technical, Git is the way OpenStack operates. So you'll need a GitHub account and every single thing is a GitHub repository. So if you look at github.com slash OpenStack, you'll see the documentation is a GitHub repository, all the code is a GitHub repository, the manuals are GitHub repository, so you will need a GitHub account. And if possible, try to use the same email address just to make life easier for you. The link below gives you a link to more details and steps of how to contribute if you wanna look up more details. And if you wanna try out, while doing your development process, if you wanna try out OpenStack, DevStack is a great way to run a test environment on your box. You get cloned DevStack and you run it. It has all the services up and running for you and you can test out any changes you're making to the code using DevStack. Here's the basic workflow. I'm gonna give a small demo of this, but just let me talk a little bit about it before I go into it. So like Arglay said, the first thing is identify how you want to contribute, be it by picking up a bug or saying, hey, I wanna work on this new feature and filing a blueprint. Identify that piece of work which you wanna contribute to OpenStack. The second is now you have your GitHub repository cloned. You wanna create a branch so that you have a separate working environment for your contribution. Make your commit, work, work, work, make your commit and you push it up for review. Okay, so this is a lot of talking. I know it's confusing. Let's go through and see what it's actually gonna look like. And for those of you who haven't got to the room a little late, there are some handouts being handed out around the room. So find someone helpful with a lot of handouts and help yourself to one. So like I said, I just started contributing to Trove. So I picked up a Trove client this weekend, I created this on Saturday. So if you look at this in the Trove client, I think I've opened up here. So there's this line which just uses the wrong parameter. This should be configuration instead of configuration ref. And so I went ahead and I created a bug for it. So if you find something is wrong in OpenStack, like even in the documentation, Launchpad has project even for OpenStack documentation. Go ahead and create a bug. Give it, you know, informative titles, some details. I'm saying like, hey, this is where it's incorrect and this is how it should look like. And go ahead and file your bug. Then assign the bug to yourself. So this is expressing intent to the community. So just because you find a bug, that doesn't mean you have to work on it. That's the best part about OpenSource, right? Someone else could do the work for you too. So go ahead, create the bug, assign it to yourself if you plan to work on it so that everyone knows. And if at any point of time you think you're not gonna be able to work on it, please unassign yourself. Cause otherwise the bug is just gonna be lying there and no one's ever gonna pick it up. So I created this bug and you can notice that other members of the community have gone on either, you know, changed the status of the bug, saying yes, this is a confirmed bug. What's the priority of the bug? So different members of the community are actively working together to help resolve these issues. So boom, that's my bug, okay? Next step, let's see. So that's my terminal. I'm using a virtual environment for those who are familiar with it. It's just so that I'm gonna be installing, for running tests we need to install packages and stuff so that it doesn't mess with my system. I've just created a virtual environment. So this is an empty directory. I just created for the purpose of this demo. The first step, like I listed, was to clone the GitHub repository. So my bug is in Python True of Client. And I've copied this, I'm here. So let me go ahead and clone the Python True of Client. Boom, it's there. So you can see it's cloned all the code. Please stop me if you have any questions at any point of time. And if you look at my Git remote, that means this indicates that I've pulled down the code from the OpenStack Python True of Client repository. Now the first step, like I told you, is to create a separate branch so that you can have your changes separate from what's the code available upstream in master OpenStack. So this is in master currently. Let me create a new branch. You can give it a bug number or something informative so that you can just keep track of which branch have your changes. So say this is for this demo. So I've created this. I'm currently on this branch. If you look at Git status, I have no changes, it's a fresh branch. Now let me go to the file which had the bug. True of Client, Compat, CLI. So it was on line 85. And this was the thing I pointed you to which said it was configuration ref instead of configuration. I'm gonna go ahead and make this change. Save it. Now I've made a change. So it's very important for you, for any change you make to try to write tests. So due to lack of time, I'm not gonna be writing tests, but I highly recommend any change you make, write the corresponding test for it and run the test locally. So I'm gonna make sure that this change hasn't broken anything in the Python True of Client. Looks good, yeah? So let me go ahead and commit this change. So you've made the change and commit messages have format. So here's the format. You need a title for your commit message. You need to say which bug it fixes and possibly give a small explanation for why you made this change. So let me quickly write that down. First I said was the title. So changes, configuration, F2 configuration and compact CLI. You're missing the C at the beginning. What? At the beginning of the line, you're missing the C. Oh yeah, thank you. Live demos are great. I know, right? Everyone says don't do live demos. I could have had a video of this. I don't know why I didn't do it. More fun this way. So then I say closes bug. So if you notice, I shot in my commit message title. So there is a format saying your commit message title should not be more than 50 characters long and it was running over 50 characters, so I cut it short. So anyway, I can put in more details in my commit message so it was fine to cut it short there. So closes bug and now I need my bug number and I can say the compact CLI used old configuration ref parameter. So that's my detail. I'm saving this commit. Now, if I look at my Git log, you can see hey, that's me and I've made this change. And the way a Git is recognizing that it's me who has made this change is because I have set up, like I've set up my Git config to say hey, this is my username and this is my email ID and anytime I make a commit, please associate me with this commit. That's done. Now, it's the time to push up to for review but if you look at my remote, get it is not linked to my remote. I can see only open stack is my remote. So now is the time to add get it to my remote. So anytime I push up change, it knows it's coming from me and it's pushing to the right directory. So I know this is a lot. So what I did was I cloned the Trove client, I created a branch, I made the change, I had a commit message, I ran the test, it doesn't break anything, hopefully, because everything ran well and now I'm gonna push it up. So if I do git review hyphen s, so what this is doing is it's checking if I can talk to get it so that I can push up changes and now if I do git remote, hey, you see get it there, add it as a remote so I can push up to get it right now. Let me go ahead and push this up. So git review. Okay, I hope this is gonna work, okay? This is the main part where I'm fixing this bug live in a demo in a talk here. I hope you didn't leave any white trailing spaces. Okay, resolving deltas, closes bug, damn, it rejected. Change ID is missing. So you know why this happened? Because I created the commit message before I added get it as a remote. So what get it does is it has change ID associated with every commit you have so that it knows to keep track of like this is the commit which is pushed up. So all the GitHub like shaws are unreliable. They change, you know, if you do any rebase or any code is pushed upstream, it's a very unreliable way of keeping track of the commit you have. So that's why get it has its own change IDs which it uses. So let me go ahead and do a commit again, amend again. So what I'm basically doing here is amending my exist commit message by using the hyphen hyphen amend. It's gonna go back here, let me save it. And do a get log. So can you see it's added a change ID? So it has my commit, my author date, the title, closes the bug and change ID. So by adding get it as a remote, it's added a change ID so that get it can associate this commit. So let me do get review again. Cross fingers, let's see it works. Boom, it's pushed it up. So if you go to review.openstack.org, let me refresh this. These are my reviews, don't mind my minus ones. Okay, so see change configuration, drafty configuration. So this is what, this was the change I made and I just did get review and it pushed it up and boom it's up there. If I click on this, this was the commit message I added. Here's the change I made. You guys saw this locally, it's the same stuff. So see it's as simple as that. Once you have your setup ready, just the one time launch pad and CLA stuff, it's really simple to go ahead and make your commit. Just clone your repository, create your branch, make your changes, commit it and get review. Bam, your code is up there. And now say I've made these changes and say Dan wants to go and review it. He's like, this is not good enough. So he can go ahead and easily, you can click on any review and go ahead and add comments over here and save those comments. So you can comment on other people's reviews. This is what they were encouraging about doing reviews for other people. So let me go back to the slide. So I found some work to do, which was my bug. I know I'm reiterating this again, this workflow again and again because as soon as you have this ingrain, it's gonna be so simple to contribute to OpenStack. I created my branch, I pushed it up, I have a commit and I'm just waiting for reviews from other people. So what happens after you've pushed up your change? So members of the community are gonna come look at your patch, make comments. They can minus one it, plus one your change and code reviewers can decide if your patch can be approved to be merged into the OpenStack repository. So how to get people to look at your code? You can go ping people on IRC, review other people's patches on some good karma so that they can come look at your code. So it's a very interactive society. It's not as simple as I'm pushing up my change and that's it, I'm done. So see review, here are the commit message guidelines I was talking about, like having, you should say closes this bug, it should, your line length and all this is available on the Wiki documentation. So review.OpenStack is the place where you can go and look at reviews, you can filter them by projects, by people and anytime you wanna like pull anyone's codes done it's as simple as doing good review hyphen D and the review number. It's really simple once you get set up and help is always available. OpenStack has so many mailing lists. There's the OpenStack mailing list for users. This is the OpenStack hyphen dev mailing list for people who are developers. There are like at least 12 major lists for different categories. There are like 42 IRC channels. There is an OpenStack hyphen one-on-one channel for people who are new to contribution and have any questions, don't hesitate, people are super helpful over there. There's the ask.openstack.org, there's the design summits where you can talk to any of us, we're around to answer any questions and all the other people who said there were technical contributors here. Every city has lots of meetups you can look up, go work with people, be collaborative, learn from them, attend talks. It's a very helpful organization, OpenStack community. Yeah, so anything else to add, Angela and Arglay, did I miss anything? No, I think it was great. I really like how you planned that failure. It was totally planned, okay? Also, all of those steps that Icha just did for code apply to documentation as well. So even if you don't write code, you kind of have to learn how Git and Garrett work and hopefully you have a good relationship with the two of them. And as they mentioned in the keynotes, there is a great deal of need for reviewers, so. So sign up, comment, review issues. Thank you, everyone. If you have any questions, feel free to ask us. Thank you, everyone.