 Good afternoon. Welcome to scale. My name is Anthony Chow. I am a software developer. My employer does not endorse the sponsor me for my open source work, so I'm not going to, I'm not listing who my employer is. I am on Twitter. GitHub, you probably don't find much. My objective for 2016 is that I will have more presence on GitHub so that I'll be able to contribute more or do some work on different projects. And I also blog. The blog is for me to pick up, I am on a journey to the cloud. I read a lot of things and every day when I read something I think is interesting. I blog about it. The reason is that when I write about things, I know more detail about all those things. So it helps me and helps other people. And what do I submit to talk on contributing to OpenStack? Actually one time me and my wife went to Starbucks. So she went to get the drink I set down. When she came back, when she came back, she said, oh, you know what, today the drink is free. Then, okay, oh, I said, who paid for it? I don't know. She said, the cashier said someone paid for us already. Okay, so we enjoy the drink, go home, went home. And then in the afternoon and the evening when my daughter came back home, we said, oh, you know what, today we have a strange experience. We went to Starbucks and it's free. And my daughter said, so did you pay for the one behind me? Me and my wife said, what is that? Oh, they're supposed to pay for one behind you. This is called pay forward. And this is exactly what I'm trying to do here. I learned something. I'm now trying to pay forward. And then when you learn something, and this is why one thing, one reason I like the Linux community and the open source community is that everyone contributes. Later on, if you pick up something, you contribute, you wear a proposal, I'll come to a session and I learn from you. So let's start. Why do I want to contribute to OpenStack? If you read the title of this session, you'll probably think about contributing to OpenStack. Is this some of the reason that I listed that you were thinking about contributing to OpenStack? I hope this is not actually, I have to point her, I should use that. This is the classic example of not testing out the equipment. But being in the Linux community for a long time, I have a backup system. Let me bring up the backup system. So when I'm doing this, what are some of the reasons why do you want to contribute to OpenStack? What do you think it is important to you? Obviously, if you come to this session, you will think this is something useful for you. This is something listed here. You might be wondering why is this, let me get this out real quick. Sorry about that. Why would this picture is in this slide? Is it applicable? Actually, this is the reason why I contribute. This then doesn't work. My backup system also doesn't work. Anyway, what do you see in this picture? Do you recognize Linux? Dockers? Anyone know about Go? Go is very popular. I think Dockers, written in Go. What I see in this picture, there are two things. They are very happy. All the characters, they are very happy. And there's also food. You look at my side, you know I like to eat. These two things is what I'm trying to pursue in my career. I want a happy environment to work on. And also, I want to bring food for my family. So the reason I contribute to OpenStack is eventually I will be able to get a job in the car. And I hope today we'll be able to see if there are some barriers we can go over and try to see if we can start or you're not afraid of contributing to OpenStack. I think everyone of you know what OpenStack is. So I don't need to go through. But there are two things I need to point out. OpenStack is 99.5% Python based. As of now, I still am not able to find what is the 0.5% written on. I know it's mostly Python. Most of the code we use is Python. But what are the rest? You go to Twitter, you go to social media, you will see all. It is not 100% written in Python. So if you can find out what the rest is written on, let me know also. So contributing to OpenStack, I think knowing Python is one of the big requirements. And the other one that is important for us to know is that OpenStack is a bi-annual release cycle. If you are an operator, you don't really care about the release cycle. Although you just need to one stable build or one stable release, then you'll be able to deploy that in your environment. But this bi-annual release cycle is important if you want to contribute. The reason is that when you look at a bug, if you try to find a bug to fix, this release cycle might affect if you fix, it will be merged into the mainstream. One time, how many software developers we have here? You know about release cycles. Release manager will say, oh, release time is next week. Although, you can say, my feature is very good. It's very useful. But is it safe? I'm not sure. I can 100% say then the release manager will tell you, don't check it in. This is the same thing. Because this is a bi-annual release cycle, OpenStack is released twice a year. So you have a special window to work on the bugs. This is something we need to be aware of. This is, which I have to point out. But this is something we need to know about OpenStack is that before it is using a model called incubation and integrated. If you look at the picture itself, it was an older model. You have the call. You have the integrated system. What integrated means is that they will test your fix in the integrated with other features, other services as one. For incubated, the source code is not stored in GitHub. It is stored in Stackforge. So until the technical committee decides that this feature is going into the integrated, then it will not be in GitHub. This pose a big problem is that people tend to only contribute to the integrated projects and not the other one. So it is not helping the community. So that's why they decided to call something called a big tent. Just like we are all under a big tent and also all the products is being tagged. And they are now being hosted in GitHub also. I have a link here. Today in the slide, I will have a different URL put on the slide so that we can have future references. The slide, I will put it on SlideShare. And if you look at scale, they should post it also. I think this is helpful if you can go back. Let's take a look at some of the projects. These are currently the OpenStack projects. There's a whole bunch. Sometimes every release will have new ones. I think Chef is one thing. Maybe it's not written in Python. Maybe if you contribute to Chef of OpenStack, then you don't need to know Python. You just know Chef. And there's also Ansible. Wrecked space is heavy and using Ansible to deploy a cloud. So knowing Ansible is also a good way to contribute. And this I18n, this is for translation. If you know other languages, translation is also a good way to contribute. But let's, we will talk about it later on. So we were able to find one of the current OpenStack projects. Do you feel this way with OpenStack? Have you ever worked with OpenStack? I think it is kind of a complicated system. And one reason why OpenStack is not heavily deployed is that it is not that easy to use. Although the Taiwan move on, people are doing different distributions. HP is doing some kind of, what is that called? A turnkey system where you buy just one hardware. Ubuntu has one system too where you buy one hardware. It's all integrated in and then you can deploy it from there. But it's getting better. But sometimes if you feel like this, this may be a hindrance of why we do not contribute to OpenStack. I find this interesting because I bought things at IKEA also and sometimes when I get home, it's not that easy to, you look at the picture, it looks easy but if you actually try to put the two things together, it might not be that simple. Okay, so I have to ask you this question. Why, what is holding you back from contributing to OpenStack? Any reason that I have not listed here? Doesn't matter. I hope after today we'll be able to, whatever barrier you have, it will be taken away and just look at this slide. Whenever it's impossible becomes, I am possible. I hope you'll be able to get some, get over some of the barrier. Is it some barriers you are encountering? Because this session is trying to overcome the barrier. If it is not listed here to share with the audience and maybe we can try to overcome that barrier also together. Oh, okay. So let's try to go over the process and see if that will help you. I don't claim to be OpenStack expert. The reason of the mind, I mean, I'm still learning but the objective of this session is that if we can overcome the barrier and you start contributing to OpenStack, I meet my objective. So let's move on. First of all, at least, what can we work on in OpenStack? There are many things we can work on OpenStack but in the context for this particular presentation, we concentrate on how to make coding changes and documentation changes. In OpenStack documentation documentation changes is also considered as code changes. In the sense that it goes through the same testing procedures, you have to write a commit message, you have to check it in and then go through the Jenkins gait system and then before you can emerge. Anyone contribute to other open source projects? They use poor requests. This is very different. They don't use poor requests on GitHub. If someone did not know how most open source project does is that they do in GitHub, you will call it to your repo and then you call it to your local machine. You make a change to you, to your GitHub account and then you do a poor request and they will merge whatever in. But in OpenStack, it doesn't work that way. You don't submit a poor request. You will just submit it for Jenkins for review. We'll go through that later on but you will go through a code review and also a unit test system before they will merge it for you. This is also a good link on how we can contribute. Like I said, testing is very important too but I'm not sure if this is something you want to do. Testing because there's also bugs that someone report a bug, you want to call something called a triad. I know I didn't say the word quite right. The triad process is that you test out the bug to reproduce it so that people can work on the fix. To prove that indeed this is a bug. This is something we can know. If you know other languages, you can do the translation. I know in China, in Japan, and also in Korea, they use heavily an OpenStack and if you can translate the documentation into the respective languages, it would be useful also. If you want to see what we can do, go to that link. I'm not going to go through it here today. Before we choose what to do, there are a few things that we must do is to create this account. You have to create an account and launch part. You have to join the OpenStack Foundation as the individual contributor. You have to sign the agree license agreement and use it also. This is a system that you have to create an account also. On your local machine, there are two things that we need to do is to install, get and review. In fact, on this machine, I do not have this installed yet. Maybe it's a good time for me to do. I am mostly a Ubuntu user. I don't know much about Fedora's NOS. Get, install, get. It's a very simple process and it's pretty quick. They do have a fast network. I think the network here is faster than the one I have at home. Get, review. This is another thing that we need to install on the local system. If you want to contribute, these are the two things you must have. Of course, you need to have the Python and the one that we will go through it later on. Let's see. This is, these two URL described about this process very well. So, I hope if we have, you have time and you have, I don't think you will get stuck. But in case you do this one from Sematic.com, have all the, have all the screen print that talks about which field you need to fill in. It talks about the whole process and then this is like if you go to Launchpad to create account, these are the things you need to fill in. It goes through the whole process. I don't think you guys have, we have problem with this but this is put into the slides for, just for reference. Current slide. So, how do we find bugs or how do we find things to work on? They have a bug system. So, the bug system, again, this is a very important URL that we need to know. In the bug system, it talks about, they have different status and they have the priority. It's being a critical high, medium, or low. Of course, if you have a low priority bug and it is close to release date, most likely they will not merge it into the, into the build. And then if it is the status, it's something we need to take a look when we find a bug in the bug system, as that we have to pay attention to the status. And this, this the triart is the word I'm trying to say is to that people was trying to repeat the test process and to see if that is, that is indeed a bug. So, but how do we find a bug? Not here, this one. This is where we find, try to find a bug. This is all the OpenStack bugs. It's listed in bugslaunchpad.net. Well, of all this, how are we going, which one is suitable for me to look at? Am I going to go through all this and try to find a bug? Well, this is one thing, is that we can go to the advanced search. This will limit the possibility. Well, status, for me if I want to choose a bug, I would not try to put a new bug because when a new bug is reported, it might not really a bug. So, let status settle down first. At least the confirm is very good that we need to search on because if it's confirmed to be about then we, this is something that we should choose to work on. And of course, in progress, means someone is already working on, unless you want to work with the other person, it might not be good fix committed. Of course, we don't want to search for that because it's already fixed, it's committed. For incomplete with respond, that depends on how you want to find a bug. Sometimes there are incomplete response and if you can take the initiative and follow up and fill in the problem that will also help. So, it depends on how, what type of problems you are trying to find then these two may or may not be useful for us. And for the assigned E, for me, I will choose nobody because that means that bug has not been picked up by someone or being assigned to anyone that's working on. Although that might not be a problem too, what I find is that some of the bugs that they have, they assign to somebody but and then later on when you go back to the log, it's that oh, that person is inactive for half a year already. Even though it's assigned, so you can still pick it up to work on. And this is some of the, you can fine tune the search. So, let's see if we pick this, how we can find some bugs. Well, you can, so many of them, let me instead of go and go back and then do a search. Then the limits still, we'll be able to find almost 3,000, 3,000 results. Then again, it's difficult. How do we find a bug to work on? One thing good about is that in finding a bug for OpenStack, there is something labeled as a low hanging fruit. And these are being tagged as a problem that's suitable for the first time committed to work on. In the mailing list, I talk to say, oh, how about take away the low hanging fruit and tag the bug as suitable for first time committed. But I was on the mailing list and then I reply and say, oh, this will not be good because I have submitted my first bug that I don't qualify to be a first time committed. But still, I am a casual committed for OpenStack, I don't work on the very detail. So, low hanging fruit is still important to me, so I think I hope they will not take. But if you go and search with this tag, then this is something I would suggest this is good for first time committed. These are the bugs that is labeled as a low hanging fruit that means they should be very easy to fix. And I recommend doing the search with this tag, so we just try to find something, wow, they have so many problems for fuel. Then this is one way we can find out what is a good bug that we can work on. If you find a bug, what do you do? Maybe you can, for me, I am a more cautious person, I will not immediately assign the bug to myself. Let's see, we go back to the slide, this is what I will do. Let's see, let me find, there must be some problem with the flip office, you should be able to see the slide, finding something to do. Another good way is that in the open source community, IRC is your friend. See, it's slide show, I'm not sure why it's not letting me get the full slide, maybe for the whole presentation we have to live with this kind of a format. But IRC is a good way. There are two things about IRC, let's go to jump to this and you can, I'm not sure if you have IRC client in your workstation, if not I'll use this web bay, web chat, three, no, dot, say ORG, I forgot on dot net, say three, no, dot net. This is how we lock in, I use, every way I use, I use this. Which channel? I make a mistake before I was going to open stack, it is not a right good channel for developers, actually it develop a depth, it's a good, good channel. Mountains, this one, this one, this one, this one. Did I miss anyone? I am not, well, probably it's not using IRC, let's see. Huh, select all the, this one, this, is this one? I, let's see, no more? Did I select all? It's only two? Let's see, yes I'm not a robot, I am not a robot, yes I am. See, this is how we lock in the IRC, there are two things about IRC, this is, you can ask question about IRC, and also different committees, they don't, they do not hold the meetings at, uh, opens this, on this channel, but they have individual, let's say if you country, want to contribute to Neutron, they have, um, weekly meetings, I think they're trying to go with the bi-weekly meetings too, because there are two different time zones, people can attend different meetings, but this is where it's discussed, what to check and if you are new to, uh, high scale, so someone, someone is locking in the IRC too, it's one way with that, I can ping that person and I'd be, is this someone in our audience? Hi, good, thank you for, for locking in, then I ping him, this is someone, if you wanted to contact someone, let's say if the bug is being assigned to him, and I want to work on it, or I want to ask question, then I will say ping him and then if he is online, and some people, they have a IRC proxy, they will appear to be online, but they don't, it's not there, they will answer you later on, so you have to pay patient, and then you have to find out whatever project you want to contribute to, what is the best time developers, uh, go to IRC and, and talk, then you will have to adjust to that time and talk to him, so if you, let's say, or, let's see, I can ask him if I can work on that bug, and then he will just confiscate, he will just go on and on, and then eventually, I'll say some people are very, I would say people in OpenStack, I have that in the one of style, people are very friendly to first-time committers, for some reason, so you just don't worry about asking the wrong thing, and then you just talk and talk, and then, um, actually for me, I was very fortunate, for my first bug, I checked in, it's a documentation bug, I was on IRC channel, I forgot which channel I was on, and then saying, uh, I'm a first-timer, some, blah blah blah, just try to introduce myself, and then all of a sudden, a guy asked me, I think it's a guy, I don't even know it's a, it's a woman or a man, but he's asked me, oh do you mind not working on documentation bug? I said, oh no, anything is good, then he get me a bug number, and I sign it to myself, you know what that bug is? It's take out two right spaces, that is the bug, see, actually, go out contributing to OpenStack, it's not that difficult, see, for me, I'm lucky, my first bug to fix is, take away the two spaces, and then I run, it's not that simple, or go through it later, even though it's taking out two spaces, it still take me more than one week before my fix got merged into the main master, but anyway, this is something, you, if you want to contribute to OpenStack, you should be able, you should master IRC, and then use it as a tool to find bugs, and to work with, because OpenStack is a collaboration of resources to work on, so if you talk to more people, you make your presence, in those individual, let's say Neutron, they're okay, they have the weekly meeting, if you attend, you just say hi, that meeting has been locked to somewhere, I forgot where IRC will lock it, but your presence is being locked in the minute, so people know that you are there, and then if you ask questions that you will make yourself known, people will know who you are, and they're, oh, such and such as here again, asking questions, they will not say you're asking stupid questions, at least they will not say it in IRC, but they will say, oh, this guy is very serious about contributing to OpenStack, that he will help you out, and will talk to you, so this is something we should be aware of, and this is your friend trying to find about, let's say, go back to the slide, and of course there's more like this, oh, I know what, let me quit, now let me, oh, still no, don't let me quit, this is something, something I don't like, I myself am a developer, I don't have a customer-facing job, talking in front of the audience is still not comfortable for me, but so, forgive me if I look clumsy or it's not as, the presentation is not as smooth, but at least my objective today again is that if there is any hindrance or barrier to contributing OpenStack, let's see if we can, through this session, we can try to overcome it, let's move on, there's also the melody list, this is, I have the URL here that you can go and this is a lot of good discussion, may not be bug-related, but they are good discussion about the project, they talk about the directions of the project, what is good, what is not good, people like this, they want this feature to be had, to be heading this way and that direction, this is very resource, very good, but then, bear in mind, I think, better not to use your work email address to sign up for the melody list, just use one dedicated somehow, some Yahoo or Gmail melody list so that you will not, you will, every day you will not be going over hundreds of emails and then there's also the Ask OpenStack, I personally do not use this much, I don't know, but of course you can ask question about OpenStack on this channel, let's move on, this is something, this is, let's say, assuming you already find a bug to work on, you have assigned yourself a bug, how can, how can we work on a bug? What I find mostly is that OpenStack developers, the year beginning systems, this is what I find, I think, you've been to in particular, it's very friendly to, to OpenStack, of course there are people from Seuss community, from the Fedora community, especially Red Hat, they use their own system, they, but I think, I would say 60 percent of the development environment user use, you've been to machines, of course you have your own choice, this is not limited, and then there's different ways to, to work on a bug, there is that you use, you can use a KVM to speed up a machine, anyone heard about Vigran? Vigran is very nice, you just spin up a VM and it's just right there for you, let's see, Vigran, I think they have a, they have some other product, there's some other product, this is how easy you can spin up a VM, so it's two rounds, and then after the VM is up, you just Vigran SSH, then you will be in that VM, you can configure it as whatever you want, and this is good for development systems, and of course VMware Workstation and Fusion, I'm not sure this is a Linux convention, not to make people, I, I am involved with the VMware community, I do have a VMware Workstation, but one bad thing I find out is that my VMware Workstation is an older one, it's version 8, it does not support 14.04, there's some, some hot way I find is that I tried to spin up a 14.04 Linux machine on my Workstation 8, and then I see crazy behavior, now actually I find out it's that version 8 does not support 14.04, but I think it's not a problem, and another two things that we look at is DevStack and RDO, usually when we configure OpenStack in the production environment we use different server, but limited if we are developer, we don't have that many resources, and even if we have that much resources it's more convenient if we can configure OpenStack in just one single machine, they have, let's say DevStack is very good, I use DevStack very, more often, DevStack is a community, you can spin up, this is very nicely described how to work, to just get cloned, and then you just spin, run the script and then later on you'll be able to start, and then you have a virtual machine with OpenStack running to work on, and of course depending on the project you work on you have add-ons, but you can easily Google your particular project, let's say if you work on Neutron, if you Google with the keywords DevStack and Neutron then you will have tons of information for you to see how to configure a machine, although I have to, I have, at least this is my problem, is that even though there are instructions to to specify the environment, sometimes it's not that straightforward, and that's where IRC come into hand, and that you can ask different questions, it's sometimes, especially my experience with the OpenStack community, is that it is not that easy, that's why I come up with this, with this, with this slice, sometimes I really feel like this way, but the good thing is that don't be afraid, it is not that simple, there are customer support on that, it's a community, it's very friendly, so don't worry about that, that should not be a hindrance, and then this is some of that, of course RDO, RDO is the San Luis Fedora redhead version of DevStack, I don't use it that much, but the same idea is that you can in a single machine or in one, you spin up one development environment, you can do your changes and test your changes, this is not something specific, and then fixing the problem is, it's depending if you have a low hanging fruit, fixing the bug, like in my case, I just have to take away two white spaces, and that's my fix, sometimes the fix is just like that, but still after the fix, the problem comes is that you have to do unit testing in your local machine, you just don't want to be a bad guy in the user community, do some changes and check it in without testing, you can do that, no one will prevent you from doing that, but this is our good practice, and then you can, there are few things, because mostly OpenStack is mostly Python based, we use talks to want, to run local testing, usually the project itself, if you're working on, they have very well developed and well tested test scripts, so you just run the, run this one, command it with this, run it for you, and this, this article, I find it particularly useful, and it very detailed, it talks about how to do unit testing, it details the script, it tells you that you need to use PIM to install talks, and then these are the things you need to do, and then you can go to, one problem with OpenStack for now is that Python has a version 2 or version 3, some project is using version 3, some project is using version 2, so it depends, and sometimes depending on the project you're working on, you will have to, but usually all the projects, they have good documentation on how to run unit tests, and this, you can go through it yourself, and this is something not difficult to do, and have good suggestion, the unit test, this one has a nice screened layout, is that you will tell you how many tests being done, and they are used as successful or not, most likely it's difficult for you to see them, because of the color, it's not easy to see, but you will see, this one is better, when 14 tests in how many seconds, and say okay, so your unit test is good to go, but this is something that we can do, but what I find is that after the unit testing, committing the fix is the most difficult, but you will think, the bug is already fixed, one is it's so difficult to commit the fix, well let's take a look, Garrett is a system, a code review system that will trigger when you check in, you will run the continuous integration test, and you'll want to see if your fix is good, the commit system, Garrett is based on a voting system, for sure you need two, two plus two, let me phrase it the other way, plus two is one, you need two of them, before your fix can be merged to the master, and also there are some times they will give you a minus one, like I said in here, minus one does not mean your fix is wrong, but there is something not quite right the format that they will give you a minus one, sometimes Jenkins, they will give you a minus one because when you run the unit test, it fails, I think what I'm not 100% sure, but what I my understanding is that Jenkins also use DevStack to spin up machines to run the test, so using DevStack or Arduino to run your unit test is also good, sometimes the problem is not on your side, it's because of some other people's problem the test fail, then you have to follow up and find out what the problem is, sometimes you can request to run the test again, so don't worry you will most likely when you do the first commit or first full commit, even a seasoned contributor to open step, they will get minus one, because they are of different reasons, people will say co-review, I don't like to do that, one of my experiences there is I forgot to mention on the release there was one low hanging foot I picked up, the problem is that they will say oh there are two flags, it's being deprecated, not being used in open stack anymore, so I'll say oh good that's the easiest thing, there's no logic change, I just need to take out the two flags, do a grab on the tree, whoever uses it, just take out the code, no problem, so I did that and I commit the code, I did the testing, they all tested well, I make my commit, some reviewers say oh it's good to go, but there is one person they give me a minus one, they said oh no, this is not how you do things, for a deprecated flag you cannot just take it out, you have to in this release mark it as deprecated, and then we will take it out on the next release, so for me okay, then what I have to do is I have to do a rebase, I have to make all the, whatever changes I make it's not good, so I have to do it all over again, and then I submit my changes and then later on on the next release they get taken out, I didn't do it myself, but commit message is not as easy as you think, it's very, because they follow a very strict, and I recommend you to go through this document before we do the commit, this is a very good description on how to write commit messages, we're not going to go through this, but this is some of the main things, don't make space, and I think that this is a good thing about this article is that you have example of good commit message and bad, and explain to us why this is going to be one that this is bad, and sometimes you might get a minus one just because the format of the commit message is does not adhere to a good commit message, so they would say, oh we do your commit message, and one thing is that later on we will go through is that because of Jenkins, the change ID is very important, we try to keep the changes, because if they're later on, or some will say you're fixed, you need to make additional changes, that will be good, then you will check in with the same new change ID, so that your fixes will be in the sequence in the lock, and I highly recommend we go through this, if you do a commit to go through this first, before you really commit your fix, I think this is something good about OpenStack is that they have this sandbox for us to play with, before we really do, this is something very safe, and I think we should be able to go through this here, and try to see if if you actually, if you have your laptop, you can also play with it, the URL is on the slide, but this is trying to do, try to play with a good, do a commit, so you see, or see this, for me already, download Git and Git review, so Git clone, let's see who were my first, see the, I don't have an OpenStack, Git, clone, DTPS, FetFingers, OpenStack, Dev, Sandbox, good, hope it's right, no, simple, it's fast, and this, you have this directory, CD, Sandbox, we have all this, what we're going to, actually this is very, I did it once, so this is very nice, I wish I know about this when I have my first check-in, I don't, I didn't, and then I have to learn it the hard way, so now we are there, let's follow, follow the instruction, see what I have now, config, this, this is done by the Sandbox, this is, I never, because I just downloaded, I don't have anything, so I need to get config, user, name, for me, something else, okay, no, config, no configure, okay, config, user, mail, actually there is a story about by this vCloud, beer thing, I like to drink beer, so beer is one thing, and my last name is chow, so when most of the joke people talk about me is they call me chowder, and I like food, so when I pick a username on Twitter, I say, I would say, and I like, I work on virtualization, so I call, initially I call myself v chowder, and beer, but later on, after I work on the virtualization someone, the cloud come into place, say, oh, there's good nice things, and myself from chowder, I change my username to be clouder, and that's how I've been using this for a long time on most of the social media on Twitter, on github, on even, I open a gmail account with this, just do that, ah, the next thing is very important for me, I have been working on Unix, Linux for a long time, but I never forget to learn Emacs, and forget the default editor is Emacs, the very first time I make a commit, I have a Emacs screen in front of me, I don't know what to do, because for me the most difficult thing is, I can do the insert, I don't know how to get out of Emacs, I have to call my wife and say, how do I get out, so this is very important for me, that I must do this on a new system, I need to change to vi, let's say vi, I don't use vi m2, I'm an old screw, just vi is good enough for me, so let's say get config, this, this is what I have, this, this is important for me by the send-ups, so I have configured my username, my email and the editor, let's just follow along, ah, this, I'm not sure we need to do this, but just follow the instruction, we'll do it now, let's say, no, let's skip that, just do your git checkout, new branch, this is checking out from the send box, we're not checking out from any three from github, new branch, so change new branch, and let's follow along cat, first file is my first change set for, what was that, well you can type it anything you want, okay, say git status, as one, but I need to add that, so git, add, that's it, git status, now I have one new file, so it's easy, so let's say I make change and git, commit, so this, wrong typing, ah, how come it didn't change, someone have to help me out here, so we need to write a good commit message, this file fixes a big problem, think what they recommend in the article is that you have one line that is between 50 characters to describe what the big problem is, then you describe what's been changed, add one new file, so the problem is fixed, this is a bad commit message, actually it doesn't really help other people what it is, but that's typical for now, one thing I forgot to mention is that writing a commit message, you have to say this is fixed, but this is a keyword, very important, let's say I will request, I work on bug 1, 2, 3, 4, this is bug fix, and there are a few keywords that you need to put on too, because if my fix change, I will say API, say API impact, of course if you change API, there's also a bug impact, these are the very keyword that we need so that the API, the group will know that this bug, there was an API impact that they need to log on, bug impact means, whenever you have checked in, affect existing documentation, so the documentation group has to take a look too, and sometimes there is that impact, if your fix has security impact, let's say your fix may be good, but it will introduce some security hole, then you need to put this in, or your fix is fix some security bug, then you put all these three, this will flag Jenkins, or a Garrett system, to inform the other group that whatever you have changed the fix has all this impact, so that they will follow up on that, and then I think this should the change ID should be given to me, let's see what it is, and how do I save and get out, is it control X? Control X and Y, enter, all right thank you so much, I thought I changed my editor, so I make a commit with a commit message, but that's not, we're not done, get status, you will say nothing, nothing to commit, but the most important is that after you do the commit, we type in this important command, it's git review, I'm going to type in git review, but my command is going to fail, it's not going to work, so see if you can figure out what went wrong, git review, it's going to fail, okay, ask me, yes, Garrett username, what's wrong, just give me a trace back, try again with this, it's a test, okay, this trace back, we don't know where your Garrett is, but let's see, they should know, so there is a git view, git review, anything wrong with this, sorry, yeah let's see, let's do this, right, but actually this is not my biggest problem, it does know where it is, but there is one thing I'm missing that I have not done, let's get her out, let's go to, where should I go, I should, this is the review, is it review open stack, review, let's sign in, this is where the review is, one thing I have not done is that there is one thing we need to know, settings, this is the key, my laptop is not set up, I don't have the key, that's why it's not allowing me to do that, these are the some of the things that might be frustrating when we contribute to open stack, this is a little thing, it's not the difficult things to do, but just that we don't know the flow, we love doing it as a second nature, so we need to figure out, but let's say if we're looking at this, these trace back and these things, even though if I do the, this one get reviewed at last, it might not necessarily tell you what really happens, and this is where Google companies to play, I think Google is the most common or most well accepted search engine, I don't think any people would use Bing as the search engine, even the ayahu, I think finally, not very friendly to use, but anyway, this is a side comment, that's not important, but this is where search engine, internet search engine is good for us, if we want to contribute to open stack and we find a problem, we just have to say, key in the right word, try and narrow as a, this thing we can say cannot connect to open, to get it, then you will try to find out what exactly, what is wrong, and for me at this time, I think I need to pull out a cheat sheet, and to create myself an SSH key, actually to do that is not that difficult, let's say, usually when I, at the, for us, and let's say cd.ssh, there is a .ssh in Ubuntu, but I need to generate SSH, T gen, minus T RSA, you can go to RSA, enter file which to say, just take the default, okay, this one is a, now, before I only have a known host, but now there are two files called, for me, this is what I need to do, is that I need to cat, id, RSA, pop, dot, pop, and then, let me put this away first, and then I need to copy this, and go to net key, paste, yeah, now I should be able to, let's see, let's take some, give it some time, usually it might not be that fast, I'm sure, let's see, go back, cd, cd sandbox, now open stack sandbox, let's do the review again, get review, see if this will work this time, because I added the key, I think this time is okay because what I see is that I have a number given to me, this is the number, and this, when we, when you do the commit, this is generated for you, then we just click, yeah, let's go there and take a look, copy, see this is what I have committed, and this is, you can see the reviewer, in this special case, this is Jenkins, Nimble Storage and EMC are up, it's the reviewer, see Jenkins give me a, because one, for me it's good to go, Nimble Storage say, no, not good, then I need to find out what it is, this is one, this is, so this sandbox is very nice to see, we can play around with it, and you can, if you have a successful check-in with this sandbox, then you can do your regular check-in for the regular bug fix, then you feel more comfortable, let's see, this is the change ID, this is important, let's see, because this is my commit message that I have typed in earlier, and what else can we get from here, this is the workflow, this is so many things we need to look at, but this sandbox is very nice tool for us to get used to the commit process at the workflow, so the key thing for me to overcome the barrier to contribute to open stack, it's not really the bug fixes, it's the process that we are not familiar with, if we are familiar with the commit process, I think it will make us more easy to commit to open stack, and let's see, I'm not sure, that's because I think this is only a test, when you do this, I think it's recommended by the webpage that we abandoned, this change, I'll get back to it later, but this is something and demo time is a sandbox play with it, and this is what I have, so like I said open stack community is particularly friendly to the first time, if you identify yourself as a first time committer, people is going to help you out, and they're going to give you advices, trust me, they are really friendly, and if you do not trust me, challenge what I'm thinking and do a first to be a first time committer, and you'll see if people are friendly to you, you can just come back and say oh they're not friendly to me, but don't feel discouraged, because like I said in this slide, you get nothing to do except, living to lose except time, but if you start contributing to open stack, well remember this slide and this is it's helping me out tremendously, in fact, let's say on my Twitter, I put that as my background, just to remind me that I need to, I need to stay focused and not to give up and try to continue my journey to the cloud, and that's all I have today, is there any questions, comments, is it helpful, I hope you go back and start contributing, when you get nothing to lose, the worst thing you get is minus one, thank you