 So, hello everyone, I'm Elvira Garcia and today I'm going to talk about how to contribute to Neutron, a one-on-one session. I've been working at Red Hat for a year and a half and I'm going to try to get you some along some of the key things that I think that helped me to get into the Neutron project. So what does this talk about? First of all, I'm going to make a brief introduction to the Neutron service and what its role in OpenStack. Then I'm going to list you some of the reasons that I think there are to contribute to this project or really to any OpenStack project or any OpenSource project. And then I'm going to try to tell you some of the key things in order to get to fix your first bug in Neutron. So first of all, Neutron is the OpenStack networking service. In OpenStack, there are many different services that allow for many different capabilities in the cloud. Some of them are optional and some of them are core. Neutron is one of those core components because it allows for all the wiring of the instances that we want to deploy either VMs or bare metal and not just that, it also wires the services between themselves. The main components in Neutron are the Neutron server that gets all the apicals to the service itself, the Neutron DB that has all the information about the networks that we defined because since we have software-defined networks, we need to save the state and the definition of all the routers, the networks, the subnets that we create. And also the plugins and drivers. The plugins are, you could say, where the magic is. It's where the capabilities are really coded. And one of the most core plugins inside of Neutron would be the ML2 plugin that is a framework for creating all kinds of link-layer resources like networks, as I said before, different kinds of networks. And inside of a plugin, you can find different ways of implementing that capability. In the case of the ML2 plugin, we find ML2 OBS, which is the open V-switch backend for the ML2 plugin and ML2 OVN, too, that it works with OVN as the SDN technology on the back. So why I think it's a nice thing to contribute to Neutron. It's really straightforward. The first reason is because you can. It's not with every project that you are able to actually get interested or find a problem and just go into the code base and learn a bit about why something is failing or how something is working. And if it's because of a problem, you can even go ahead and submit a patch for that. I think that allows for higher quality of the code and also for higher reliability because there's more people looking into the code than if it was closed source. And there's also public peer reviewing. This means that for a commit to get into the code base, there must be several people reviewing a patch and at least two core reviewers stating that whatever you coded into the project is right to go inside. So the next thing I think it's because you want to learn. So you might just be interested into networking. For example, in my case, when I arrived to Red Hat and I started with OpenStack, I only knew what TCP, UDP and all that kind of really basic stuff. Once I was here for already a year, I've heard much complex concepts like, for example, VLAN transparency or trunk port and all kinds of things that I didn't even know that existed before. So even if you're not interested in networks and maybe you're interested in other parts, I think Nova would also be nice to anyone that wants to be better with all kind of operating system technologies. And that's one thing. And the other thing is that there's a whole community of professionals from different companies that are eager to help everyone regardless if they work for another company or if they work located in another city, they will all try to help you. So don't hesitate to ask on the different channels that we have. The third thing is that I think there will be many people that actually works in a company and they might want to improve their OpenStack cloud. So I think that it is key to know that the people that actually decide the route that Neutron is taking is the people that are actually taking a part in the code contribution and their review contribution. So for example, the enhancement, the request for enhancements that are proposed there, they are approved and they're questioned by the people that are actually contributing to Neutron. So it's not just being a company that needs something is actually getting involved with the project itself because that's the only way that it can survive a long time. So let's go to the nice part, how to fix your first bug in Neutron. The first thing is to stay connected. I think no one expects you to know how to do everything related to Neutron if you've never played with the code base before. So it's really important to be in the OpenStack discuss mainly and it's really important to be in the IRC channels. In OpenStack Neutron, you will find all the reviewers and all the contributors and we will all try to answer if you have any question. We also have weekly meetings on the Neutron channel, so don't hesitate to go if you're interested. Once you're in the IRC, you can go ahead and get the code. We have a system that is, it might be a bit different if you don't come from OpenStack. We use OpenDev and GearRid. So OpenDev is a portal that contains several things. It has the code hosting, it has the continuous integration, and it has the GearRid user interface, web interface, sorry. And GearRid is a Git server that actually provides the code preview in a different way that we are used to. If we come from GitHub, because it's not based on merge and pull requests, I will show a screenshot afterwards. And along all this way, please don't forget to check the documentation because you will find there how to create your GearRid account, how to set up your Ubuntu one account that you will need to make your contributions. So once you have all of that set up, you can go ahead and find a problem for yourself. We call the good first issues low hanging fruits, so just go ahead and check for one of those in Launchpad. Launchpad is what we use to file the different bugs that we find. And once you have that, you can go ahead and deploy DevStack. DevStack is a minimal version of OpenStack that is meant for developing purposes. So it's something that you should never, ever use in production. Because it's not meant to stay consistent a long time. In order to deploy that, you can tweak the local file, which is a file that you can use in order to change the services that you want to have in your environment. You might want to have the OBS backend, you might want to have the OVM backend. One version or another, all of that is configured there. You also should know, as I said before, they are disposable because they are not expected to stay through time consistently. So whenever you finish with a bug and go to a new one, you should delete the VM that you've been using for your previous DevStack, as your previous DevStack deployment. And as the host VM for your deployment, I would say that you should use either the latest even to LTS or CentOS 8, although it should work with any OS. But the ones that are supported officially are those two. I also added here some tricks that I think are useful or that were useful for me when I started. First is to automate the deployment process of DevStack, because that's something that you're going to be doing for each commit that you upload, or almost each commit that you upload. So you might start, if it's your first time doing this kind of stuff, just with, say, your configuration is inside your own Git repository so that you just have to do a Git pool in your DevStack VM. And once you're comfortable with all the process, you can go ahead and directly have your own background file that does all the deployment by itself, and you can go ahead and directly work with the DevStack deployed. Another thing is to not shut off the DevStack VM. That's something that happened to me when I started. I will just shut off my machine when I would finish working. And the next day, I would realize that all the resources were lost, because it's not meant to stay, because, as I said, it's not meant for production. But another thing that was good for me was to take snapshots after doing a successful DevStack deploy, because when you're starting, you might do things that you're not supposed to do, and you might break your environment. So in order to avoid wasting a lot of time restacking once again, you can just go to your last snapshot, and everything will be fixed. So once you have your DevStack deployment, you can go ahead and create a small workload. I put here what would be a really simple workload composed by one router that has a subnet attached and one or more servers. And the router is also wired to the public network, so that you can get to the server. And I would suggest to use Theros as always for testing. Theros is an OS that doesn't need a lot of resources. So it's really useful because you're already using DevStack with a host VM. So having a minimal VM that allows you to just use one gigabyte of space, it's nice when you don't have infinite resources in your host machine, as most developers happen to be. So it's also important to consider that OpenStack blacklist all connections by default. So you need to know the concept of the security groups in OpenStack and to allow the traffic that you need to pass to your VM. For example, if you want to do an SSH to your instance, to the instance that you created, you will need to create a security group rule that allows for the TCP traffic and attach that security group to the server that you created. And the last thing that I said is that in order to access your VM through SSH, for example, you also need to add a floating IP to it because otherwise it will just have the private IP listed and you will not be able to get into it. So all of this is important to remember when trying to connect for the first time into your instance. And then once you have your workload, you're all set to code. Remember to reload the Neutron service after making any change because it's not whatever change you made into codebase, it's not going to be magically inserted into your deployment. Remember also that since you're going to be making all the changes into the DevStack VM, you might want to use a text editor that is not too heavy. For example, I myself use Vim for the changes. And remember to always add tests to the changes you made, unit tests, functional tests. I don't think that you have to add a scenario test to everything you do, but you can also consider that. And then I listed some tools for debugging. The most basic one would be go to the Neutron logs and check what's happening there because there's a lot of information there. And you can also add your own traces there and check whatever you want to see. It's normally the most useful thing, really. And then also I found it really useful to debug using the unit test that we defined or that we are defining. And for that, it's useful to utilize the Python Debugger program. I just put the commands there in case anyone never worked with it before. I tried to not put too many commands here because then it would be too much. But you can find in most of the slides the URLs below. So once you have your code ready, remember that you have to pass all the tests. And this is the Pepe test, which are the formatting code style ones, the unit test and the functional test. I think those are the ones that you should test yourself. And the cool thing is that because we use stocks, you can just pass the test for the certain classes that you're changing. So you don't really have to go through all the code base every time because that would take you more than half an hour. And once you finish that, you can go ahead and upload your change. And on the CI gates, the full stack and the scenario test will be executed. So I'm going to see the time. OK. So once you've done all of that, you're ready to submit the code. Or almost. You have to ensure your code is well-formatted because even though Pepe might tell you that everything is correct, the truth is that sometimes we can insert extra tabs and that kind of stuff that in the end it will make someone from the core team tell you that it's wrong and you will have to resubmit again and it's kind of tiring to do that. So ensure once again that the code is well-formatted and create atomic commits. This is something general for software engineering, I would say, but it's really important that, for example, if you were fixing the problem and you realized that every factor will be really cool in that certain class, do it as a separate thing even if you submit the two commits at the same time because otherwise it will get the code base really messy. So with that in mind, when you have everything ready, you can do a git review and see your change uploaded. This is one change I made and there you can see the open.gov.gared user interface. The votes, as you can see there, are the way of reviewing that we have. So the plus ones are something that can be given by anyone and the minus one too, but the plus two can be only given by core reviewers. When you get two plus twos, your code will be ready for submission and once you have this ready then it's just up to your peers to decide if your code is cool or not. So summing up the important things to be reminded is to communicate, to set up all the tools that you're going to need in advance, to find a good first issue. I know sometimes that will be difficult because what might seem easy for a core reviewer might not be easy for you or maybe even what might seem difficult for a core reviewer might be doable for you, so never stop looking at any problem that you find interesting. Deploy a DevStack environment and put some resources on there. Be careful and understand what they're asking on the back itself so that you actually add things that will be relevant to your problem. Do the change, test your change and add tests to your change. Submit it and wait for reviews. They will probably tell you that you need to change stuff and you will submit it again and you will have to change stuff and that can repeat for some cycles. So please always remember that they're trying always to tell you whatever is best and even if some people can look direct, that's only because they're working all the time and they're trying to be quick on what they need to say but that's not like they're trying to be hard on anyone, just plain onus. And once you have your plus two, that will happen, I can assure you, then you will have your code submitted. So that's all from my side. If you have any questions or if you're interested in anything, please go ahead. So any kind of contribution is really helpful. So comment, check the documentation, file a bug report on Launchpad or just comment, ask questions because that's also a contribution because perhaps there will be other aspects of things and how OpENSTAC is used which can help us to make it better. Of course, if you have a bug report and you have a solution that's the perfect thing because we are few at the moment and we have no time to fix everything. That's the same for the code reviews also. So if you have any kind of code which you push to get it even for documentation or the CI or whatever, it's totally possible that there will be nobody for days who will check that. So just come to the IRC and ask for review, ask for help what to do. So it's easy. So we try to help everybody to make it better and make it maintained and working for everybody. Thank you very much. Very awesome. Not related to a bug but when I found some option or some padding in the code and I wonder why it is set this way and I think for my use case it would be better if it's different and what would you suggest is the best way to ask you people why is it set back in the days this way? Sorry, can you repeat? So we found some option or some function call and we was wondering why was it set this way? And my question is what is the best way to contact the neutron people to ask what is the reason this is set this way or is there a good reason to have it this way? I think any core reviewer would be a good person to ask about our technical questions. I think in the IRC itself if you just put the nicknames of two or three people they will actually be aware that you talk because something that sometimes happens is that if you didn't talk someone it's really easy that they were working on another thing and the comment just passed because we have this functionality that puts the new code merges and all of that so the message go up and up and get lost. But yeah, I think either that or contacting one single person that you've seen that has worked on the different commit submissions just send an email to them if you want to make sure that it arrives to their mailing inbox. And when I contact the IRC should I do it at a specific time frame or on the most core reviewer also reading what's going on during the night? I think that depends on the person itself. I don't know where you're based but most people are from Europe and are on the same time zone but there's also people on the west coast of United States so yeah mostly that time zone. Okay, some other question? So if no one has more questions thanks everyone for your assistance you can always talk to me later through the email and I'll be glad to help.