 Okay. Have I done? Yeah. Okay. Thanks everybody for waiting and welcome. I am Victoria Martínez de la Grusa and we will be presenting here with Ashley at the end of the life of Trap Contributor. So, first of all, who we are. I have been around OpenStack for a while now. I started as a GNUM, OpenStack Inter in Ryzen Project. And then I also did a second internship. It's called Google Summer of Code in a project called Sucker. Currently, I'm a software engineer at Rehat. My main focus is through OpenSucker, where I am currently with OpenBoss projects. And in my free time, I really love helping new people to get involved with OpenStack. I generally do that in a channel in a university. It's called OpenStack 101. So, after this session, if you want to meet me, please join the channel. And Ashley, I will let her introduce herself. Page page when I started working on Trove. Before that, I'd never worked on OpenSource before. And yeah, this is all, I've just gone through this whole getting everything set up thing. So, well, what are we going to see in this presentation? When we were working on this presentation, it's like we were thinking on how the process of getting to be a new contributor for OpenSource project is an issue that, in case of OpenStack, that is so big and it has so many projects. First, it's like, okay, you're getting more. You see a project. Maybe you start digging into what that project does. Then, once you pick a project, you start trying to see, okay, how can I contribute? How can I set my contributor accounts? How I set my development environment? How I do things like bug fixing, reviews, feature proposals. How we get in touch with the community, which you already saw it's so big. It's like overwhelming where I do start. And that's what we are going to cover in this presentation. Again, we split it, so we have in the first part, we are going to talk about true precisely. And in the second part, we are going to cover how to contribute to OpenStack. These parts of the presentation are independent. The how to contribute part, you can apply it for every project in the stack. And the true part, well, is so you had a feeling of what is true. So, first, we are going to talk about true. Why true? That's generally a people doesn't know what true is. Companies that are trying to develop database driven application often find that they cannot get, they have to wait for months to get a database provisioned for the needs. And generally, the time of these increases when the amount of data they have to manage in their application is big. And also, it takes a lot to enforce security in those data stores. Also, in other case, for instance, there are companies that already have their infrastructure, they want to try another technology because maybe it will make things faster and easier for their deployments. But it's like they cannot test a new technology like so easily. They have to put a lot of money on that and a lot of time. And it's really, really hard. So, true aims to provide an easy and a standard way for developers to access to the future of relational and non-relational databases without the burden of having to deal with all this complexity. Something I want to stop here and make clear is that true is not a database itself. True doesn't store data, you cannot issue queries to true whatsoever. True sits below a data store of your choice and allows you to provision that data store and to manage it. Some highlights about true. Currently, true has support for many relational and non-relational databases. It has support for MySQL, Postgres, SQL, MongoDB, Redis, Cassandra, Coachbase, CoachDB, Vertica, DB2. And I'm probably missing some because it lately has grown a lot. And another important thing is that true has been designed to run entirely in OpenStack. Since its beginning, true developers focus on non-reinventing the wheel. They rely on the OpenStack projects to do everything, to provide their data store with the other OpenStack components. Right now, true is relying on NOVA, Neutron, Cinder, Swift, Glance, and Keystone to perform its tasks. As I mentioned earlier, main feature for true are provisioning and deprovisioning data store instances. But it also have functionality for administration, for configuration to make backup and restore those backups. And to do also clustering and replication with our maybe the most interesting features right now. So let's take a look on the true architecture because knowing what's going on under the hood will allow you to understand better how to get involved and start contributing code to this project. In this diagram that I took it from Tessora, Tessora is one of the main contributors for True project. And they also have a lot of great diagrams and stuff that we can use. So I took this diagram from Tessora website and it clearly depicts how true architecture is. This diagram, we can split that in two parts. We have here at the left side, we have all the components of true. And in the right side, we have the other OpenStack components that True relies on. In the very right, we have Keystone and Neutron, those components True use for authentication and networking purposes. And in the middle we have Nova, Cinder, Swift and Glance. True use Nova to manage the compute instances it needs to provision databases. It also relies on Cinder to manage the volumes for storage. When you do a backup, the backups are going to be stored on Swift. All the images that have the information, the bits for the data storage you want to provision are stored in Glance. Now let's focus on the True components itself. On the top we have the True API, we have the True Task Manager, the Gay Station and the True Conductor. All these parts interact between them through a message bus. We use this message bus to perform different operations. The True API, I won't go into detail on which are the responses for each of them, but at least I'm going to explain a little what is their functionality. A True API has its main purpose is to get requests, translate them in some format that True can understand, validate those messages, and therefore want those messages to the True Task Manager and the True Gay Station. It's the interface with the user and it's in charge of everything of command and control of the data storage you have in True. Then you have the True Task Manager, which is the one that makes all the heavy lifting as far as provisioning instances, managing the life cycles of the instances and issuing commands to the instances. It's also in charge of communicating with the Gay Station to start the data storage and manage things. Then we have the Gay Station, which is one piece of True that is running in the guest and is in charge of communicating with the data storage and configuring the data itself. And lastly we have the True Conductor, which is a piece of True that is running on the host and is in charge of interacting with the database in the host to keep track of the statuses of the instance that will be managed by True. So, like this, if you take a look at the code, which is you are going to do if you are willing to be a contributor for True, you will see that in the code True, in the Go for True, the same structure is followed and it's very easy to, once you understand the purpose of every component, it's very easy to start contributing. So, note that we have the concept for this. Let's analyze how is, for instance, the process of flinching a new instance. When you want to launch a new instance, you will issue a create command to the True API. The True API will take that message and then forward that message to the Drop Test Manager. And the Drop Test Manager will communicate with NOVA True HTTP to start the creation of a new instance. Also, it will communicate with Cinder to create the volume and with Glance to get the image that is going to be used to launch that instance. Once the instance is up and running, the gaze agent will communicate with the True Conductor to change the status of the instance to active. When you launch an instance in True, you will see that it has several different statuses, going from active when it's already working and running, error if something was wrong, or building when it's building. So, that is roughly how True works. And if you're interested, here Ashley will tell you how to start contributing to it. Thanks Victoria. So, now that you've decided to contribute, I'm going to take you through the things that you need to know to get started. The first thing that you'll need to do is set up some contributor accounts, the first one being Launchpad. Launchpad is not an account associated with OpenStack, but it is used for a lot of the authentication, particularly with Garrett and the sites you'll need to use to access bugs and blueprints. You'll also, once you've got your Launchpad account set up, need to join the OpenStack Foundation as well as sign the individual contributor license agreement. Then the last thing that you'll need to do to get things set up is to create an SSH key on the machine that you'll be contributing code from and upload that to Garrett. Once all the accounts are set up, we're going to deploy Trove using RedStack. This isn't the only way to set up Trove, but for the purposes of getting set up, it is the easiest. RedStack is a script that allows you to install and interact with the developer installation of Trove. To get this set up, we'll need a machine with a quad core processor, 8GB of RAM, an 80GB hard drive and some form of virtualization software. The next thing you'll do is spin up a VM with Ubuntu on it. We want to make sure that this VM has at least access to more than one core and preferably 8GB of RAM. When you run RedStack with fewer resources, it will often fail. Once that is set up, you need to install Git and pull down the Trove integration repository. Once you've got the Trove integration repository, you can navigate to Trove integration scripts and then run RedStack install. RedStack install will install all Trove's dependencies as well as Trove and then bring up the services for DevStack as well as the API and task manager services for Trove. Once that's done, you will need to run RedStack Kickstart MySQL to create and load the MySQL guest image. In the event that you have to reboot your VM, you can use RedStack Start to get all the services back up and running. Now we're ready to find a bug. You can find bugs on Launchpad. Once we have a tag that is often on bugs that are easy to fix, it's hashtag low hanging fruit that can be really useful for finding bugs that are easy to start off with. Once you find a bug, you should try and reproduce it yourself. If you can reproduce the issue, then assign it to yourself and you can start working on it. In the event that you can't reproduce the bug, you can add comments to the bug to ask the submitter for more information. Once you've re-prod your bug and it's yours, you can go to the Trove repository in OpStack and then check out a new branch. You can check out a branch using git checkout-b and the convention is bug slash the number of the bug for the name of your branch. Now that you've got a branch, you can start coding your fix. Once your fix is coded, you should be running TOCs before you send any code out for a review. The reason for this is it runs the unit tests and it runs the style checks. We want to be sure that before we're sending any code out to be reviewed that it is correct and that Jenkins won't automatically minus one it because it's failing unit tests. That way it reduces the churn on additional patch sets getting sent up. Now that we're passing unit tests, we want to send our code up for review. Since this is your first patch set, we need to make sure that git is set up to work with Garrett. This is where you'll test that your SSH key works, the one that we uploaded to Garrett at the beginning. You can test that with git review dash s. Then you can use git config to configure, get to use your Garrett username. Occasionally, there'll be a little trouble here. The developers guide on OpenStack is really good with additional information on this step. If you run into any issues, that's definitely a good document to check out. Now that we're all set up to use Garrett, you can use git commit dash a to stage your changes and commit them locally. This is where you'll add a commit message. There is a document. I'm not entirely sure where to tell you the exact format of how to submit your commit message. But it's roughly a 50-character title, a blank line, lines no longer than 75 characters, and then I think it closes dash bug colon with the number of the bug to link the bug that you're working on to the submission. Once you've completed that, you can use git review to send the code to Garrett for review. When you do that, the Jenkins will run the unit tests that will include the tests that we ran with TOX earlier, plus a few more. And if that fails, Jenkins will minus one the review and you'll have to figure out why tests are failing. Then you'll also get feedback from reviewers who will either plus one or minus one your code. In the event that you get minus ones, there'll be a comment to tell you what needs to be changed. Then you'll go back and you'll make alterations to your change and then you'll once again run git commit dash a. But since this isn't a change to an existing patch set, we want to use dash dash amend to make sure that we're not creating a whole new change. And then you would run git review again. And when you do git commit dash a dash dash amend, you will also get the opportunity to amend your commit message. So if something needs to be changed in that, that's where that would happen. And then you would run git review again. So this cycle of making a change, updating your patch set with git commit and then sending out another patch set continues until you get two plus twos from core reviewers. And then there'll be a few more tests run and the code will be merged. And then when the code is merged, Jenkins will also resolve that bug that was associated with the change set that we added in that closes bug tag in the commit message. So to look at reviews, we go on to review.opensack.org. You can on Garret, you can filter by project and status. You can also in your own settings add projects that you want to watch so you can specifically look at the projects that you actually want to see reviews for when you click on the list of watch changes. When reviewing code, if it looks okay, you can submit a plus one. If there's something you don't understand or you would like clarification on, you can submit comments without a rating. And in the event that you would like, there's something that you see that's not quite right and you would like to be changed before you approve the, say that the code is good to go in, you would submit that comment with a minus one. But you should always, if you're submitting a minus one, be providing some feedback as to why there is a minus one. Because a minus one without any information is pretty useless. So at some point, you're going to want to submit a feature proposal. One way to do this would be to add an item to the agenda of the weekly meeting on IRC. And that will allow you to, when you attend the weekly meeting, bring that up and talk about it with the community. You can also, after that conversation, send out a proposal to the mailing list. And then there will be things like blueprints get created as part of this and part of the discussion that happens. When you send out something to the mailing list, make sure that you follow the thread and can incorporate any feedback that gets given. So now I'm going to talk about how to get involved. On FreeNode, there are a number of IRC channels that we use. Trove has its own open stack. The weekly team meeting gets done in open stack meeting alt. Then there's open stack dev and open stack 101. Open stack 101 is great for really beginner things that you don't want to seem silly, but everyone has to start somewhere and there's no judgment there. And people in the community are generally really, really happy to help and provide feedback and that sort of thing. Also, there's the open stack and the open stack dev mailing lists that you can subscribe to an email. And then other things that you can do is sign up to askopensack.org. That's a place where you can ask and answer questions and see the answers to other people's questions that they've asked. You can come to the summits and attend Trove specific sessions. There's the mid-cycle meetups that happen between the summits and in the lead-up to those, there's conversation on the weekly meeting. And then there's the open stack user groups, which you can look and see if there's one near you to find out what's going on. And now on to tips and tricks. Victoria, did you want to start? Sure, yeah. Tips and tricks. Stuff we have been learning over experience in open stack is don't ask if you can ask in IRC, just ask. I have always seen in the newcomer channel that people say, hey, can I ask a question? It's generally not advisable because developers that are working full-time in the projects are really busy and they will look at that and they won't come back later. And probably if you ask first and just leave that question so everybody can answer, you will get a response quicker that if you ask, if you can ask. Also, I have seen a lot that many people send private message to the members of the community directly. This is, I would say you shouldn't do this because for several reasons, not because you are boring anyone but because open stack is an open community and if you ask things openly, probably you will get feedback quicker you will get more feedback from different people and people that will have your same concern will be able to look at the logs and get their concerns replied without having to ask again. Alright, so the next one is if you're new to reviewing it is a really good idea to read what other people are writing in reviews, understanding what other people are saying in reviews helps you to understand the code and in a lot of cases can help you to better identify the sorts of things that can become issues. In the event that you're working on a bug and you're not quite sure on your fix it's always perfectly fine to, if you've got a solution and you would like feedback, ask the people in IRC. The developers are happy to provide feedback there and give you the pros and cons of the solution that you've come up with and maybe even make some new suggestions. So when you are fixing a bug or you are working on a feature or you are trying to deploy open stack and you are hitting with all of the errors take another task and get your mind away from it because it's really common that I saw people struggling with the same issue and they're like trying and trying and trying and they get exhausted by trying to solve the same thing and they waste days for that and if you put your mind in something else you will probably come back with a different perspective and will be able to solve this. But in the case that you are still blocked and have been passing hours and days and weeks and you have the same issue as someone in the community make sure that you might consist questions like for instance if you are having a problem with a component in open stack check the logs, try to see there is something else as you will generally get a trace and ask the community in one of the channels we mentioned hey I have this issue in this module and I'm getting this trace so people will be able to help in a more practical way. When it comes to having issues and wanting to follow up traces you don't want to be pasting traces and logs into IRC it makes a mess and often times you will get blocked for sending too many messages all at once for that you can use paste.openstack.org essentially you can paste your traces and your logs in there and you are provided with a link that you can then put into IRC and it's much more effective. One other tool that is really useful is everpad open stack and that's useful for collaborating with other people you get a notepad that a bunch of people can contribute to and this is really useful like on Trove we use it for the weekly team meeting and for whenever there's sessions say at the summit or at the mid-cycle meet up so that people can see what's happening and contribute to the document. I think that was... Yep, so if anybody wants to contact us you can find us in the IRC rooms these are our IRC nicks and if you want to access the slides from this presentation Victoria's put them up on speaker deck. Do we have any questions? And if there are any questions can you use the mic over there so that we can get them on the video. Oh, there is a question? Yep, go for it. So before I join the meetings is there a way to sort of get past history of where the project's going sort of like around scalability and robustness and stuff like that? So there are logs from the previous meetings like the IRC logs are all accessible and the meetings use I think meeting bot or something like that that records all the minutes of the meeting that you can then go through the previous meetings and see what's happened and I think there's a lot of... all the project information is available on open stacks infrastructure like the wikis and that sort of thing. Like blueprints and stuff like that? Yeah. Thanks. Can you just put up the previous slide so we could... Oh, good call. Yeah, when you assign yourself a bug I was wondering are there times when bugs remain open for a long time and is there a process for pinging the bug owner and asking him to either make progress on it or reassign it? What's the... Well, yeah, it's really common that there are contributors that take a bug and maybe they couldn't solve it and they have assigned it for months and months. If you see a bug you are interested about and you haven't seen activity like in two weeks feel free to get in touch with that contributor and ask him he's generally a good idea to contact them first because they might be working on it and they probably didn't say anything to the community but get in touch with them, ask them and if you don't get a response then feel free to grab it. Okay. And also if you're new to a project is it better to look for low severity bugs to get started or it doesn't matter you can jump right in and try to fix something that is either critical or important? Well, I would say that it's generally advised that you take a low or medium priority bug because critical or high are generally taken but the more active members in the community and it's expected that they are quickly fixed. If you are getting involved just like given your first steps you will less pressure if you take a low or medium. Thank you. Important thing. So I apologize if this isn't the correct place to ask but I'm a little confused on the architecture and basically for this image does Trove actually do the install of a database or is that meant to be part of the image? How does it work with configuration management like puppet like where's the relation there? Which one handles what aspect? That's actually a great question. I forgot to mention in the presentation but the image creation process is something that you have to do apart from Trove is there are tools in OpenStack there is one tool that is called this image builder that allows you to create an image and add elements to that image when being elements for instance in this case of Trove you will have to install the case agent and you will have to straight the data store you want to install for instance to create a MySQL database you have to install the version of MySQL you want and you will have to install a part the case agent once you have that image created you have to upload that image to Glance and for automation I will have to come back to you for that How are the features for a release kind of determined I mean what is the process for taking account of the customer requirements I mean the various instances where Trove is getting deployed in the field how does that input come back into the feature process and how does that get determined Sorry I misheard of what was Could you repeat the question? How do the features for a release of a Trove release get determined what features you want to add and how does that take into account the requirements coming from the customers or the users of Trove So generally the features are discussed when the cycle for the open stack cycle starts like this week and then we have like a period in which aspects for these features are proposed are reviewed by the team members in this presentation we only mentioned that if you have a feature proposal in mind get in touch with the team so they can guide you to that process because it's quite a long process and probably you want to discuss with the community first if you are here awesome you have the community here so you can discuss your feature in person but if maybe you are not in the same place that the developers you want to join an IRC or in the newsletter and say okay I have this feature what do you think, how can we develop it when we can develop it and then that process of the spec and thing I was mentioning starts That answers the question Do you have plans to integrate with heat or use heat for the instance provisioning and orchestration? So we are using heat right now but for a different purpose perhaps I'm ready to or someone in the audience maybe more involved with that can reply this Sorry, what do you mean? Do you have trove used heat to provision NOVA? What are you asking? The latter, I was wondering if it makes sense for trove to use heat orchestration to provision and orchestrate and automate instances Do you have support for flustering and replication? When will the trove with depth platform accommodate those different database? I'm the person on it Any other questions? Looks like we are out of time In case you guys are interested I'm going to ask everybody here who is a trove contributor to raise our hands So you wanted to meet people who are working on trove for all here You are in the right place And work with them as well Okay, thank you everyone