 Good morning, everyone. The title for this presentation is OpenStack CIC for everyone else. Before I start this presentation, well, given that during the morning we have an amazing demo for CICD, I just want to just let you know that this is something a little bit different that we share during the morning, but it's a little bit related to what we try to do. During the first slide of this presentation, I am going to walk through the problem statement that has a developer face, so hopefully you enjoyed and found this useful for you. Well, my name is Victor Morales. I work for Intel Size 2011. I am an OC cloud engineer, OC, maybe you have heard about that, OC extends for OpenStack Innovation Center. Basically, it's a collaboration between Rackspace and Intel in order to try to make, to improve the enterprise readiness for OpenStack. I am also an OpenStack GDL co-founder. I'm born in Guadalajara, Mexico, so there is an amazing community there which we are trying to collaborate. Now in my case, my participation is more remotely, I am still trying to be present in most of the sessions, and, well, my passion is obviously system, doing programming. I love to type different programs in different languages. Given that, I have been in different companies and I have been seeing the same principle, the same things. So basically, as a programmer, you start with a solution or try to, you try to provide a solution for a simple, for a company or your customer, or maybe you have an idea. You want to implement something new, you want to innovate in a specific areas, you want to do something creative in that specific way. So you start with that idea or with that solution, and you elaborate a lot of things. You basically, you grab the information from the customer, you start to make your analysis, you develop the application, you create a couple of tests, you do a lot of things in that specific area. So yeah, you have the application, you test it, you deploy it, maybe in this case you use OpenStack, and everything is perfect, right? The customer may be happy, or maybe that new idea is something that you are creating something cool. But once that application is over there in production, and you have a lot of things there, maybe the customer is so happy and he wants to add new things. And those new things definitely probably could compromise the existence or the current pictures that the application has. So the application is still fragile, and maybe adding these new things could be broken some other parts of the application. So you have to be careful in order to fix those things. Or maybe you only have to fix a specific book, but again, this application is fragile, so you have to be careful of doing whatever change that you have to do in this application. So thanks for a couple of guys that developed these technologies. Firstly, we have continuous integration, and continuous delivery, or continuous deployment. Continuous integration is a software development practice, which basically is focused in having continuously integrated the work that the developers are doing, and what I mean for continuous integrating those things. That means that also is running a couple of tests, ensuring that it is not breaking anything. So this is one of the benefits, like you are ensuring that in every single commit or change that the developers are doing, you are verifying that it is not broken anything. But on the other hand, we have continuous delivery. Continuous delivery and continuous deployment is pretty much similar. Both the idea is to have all these changes, all these changes that the developers are doing, ready for in a stage where you can, as a final decision, take those changes and deploy it in your servers. So this is nice, and these methodologies have been there. You know that Martin Flower who basically wrote these quotes, they have been doing a lot of research on that. So great, we have the solution we don't have to remain till the well, but what is the problem? Well, the problem is in the current market, we have several solutions, all of them, in this case all of these are open source solutions. For example, in the left side, we have a couple of book trackers, like a Dreadmine track, Book Seal and Mantis book tracker. In the middle, we have a couple of continuous integration tools. Just a few of them is Jenkins and Trevi CI. On the left hand, we have system control versions, and the problem with this is given this amount of tools and different possible solutions, you have to figure out the way to connect all the single things. It is not easier, it is something that you have to spend time to investigate, you have to figure out which is the best tool that fits all your necessities. And it's time that you have to spend, like if you have a small team and you are a startup, you have to spend your resources, instead of those resources, spend time to continue adding new features of holding books, you have to investigate or make that analysis for you. So that is the main purpose, that's the problem that I face when I was trying to create my application for the tests, for my masters. So for me, I have an idea, like, well, what about if I would be possible if I can just put an idea of the solution, maybe let's say less than one day in production, but not only putting the idea of the problem there in the production, it would be amazing if you can maintain that application after the deployment cycle and keeping all these things or this fragile application there during the whole application's life cycle. So I think that most of the companies have these things. So for the solution of this problem, I try to divide in two simple things. One of the phases of this project, if I consider, was the analysis that I made in the several different components, and the second phase of this project was how to integrate all these components and having a single solution. So for the components perspective, I consider just a couple of components that I consider crucial for having a continuous integration tool. In this case, I consider an application automation server, which is responsible for orchestrating things, the version of control to store the different versions of the application, a build system, which is just packaging the application and having a release unit, a book tracking system, just something that you can track all the problems or the new enhancement that you want to do it, notification systems, something to just let you know that if something is broken or someone has been reported a failure, and account analysis reports. During the analysis that we did later, we consider that some of these tools depends on the languages that you are using, so for example, in the case of the build system, if you are using for your application Java, maybe you need to use Maven, Grail, and for example, something different like if you use Python, C-sharp, or whatever application. So that's the reason that some of them we didn't consider for the first phase. For every single component, we try to just focus in five things, well, in this case, sorry, in four things. The first thing, we consider that it will necessary to have the proper license. I only consider open source licenses for these reasons, but it's good to know that we have to pay attention what is the license that we are using for this application. There are a lot of options or things in the market, but if you have more things to offer for these different components, it will be amazing, so we try to evaluate every single component in what are the features that it's offering. Level integration, what it means for level integration is, yes, it's nice to have great component with a lot of features, but it's also important that this component has the ability to connect with other components, so that's the reason that we consider the level integration for this one, and the last thing, and not less important, that those components need to be insolvable. That means, yeah, there are many solutions in the market where you can only, they are exposing the services and you can connect them, but it will be better if you can have all these things in your own infrastructure. So I will go through every one of these components, it is not too much. So basically for the automation server, I'm considering Jenkins. Jenkins has been there many years ago. Actually they changed the name from Hudson to Jenkins, the license is an MIT. We have been using the OpenStack community for a long time, it is reliable. The way to install things is pretty, they consider it easier, but yeah, after a couple of changes, yeah, it is not as easy as we expect. The good thing about Jenkins is like it has a lot of plugins, you know, the flexibility is amazing. We can also connect notifications systems, it's nice to have with the connectivity with Git, GVS, version, anyway, Jenkins is a good actor here. By your hand, talking about the book tracking system, well, at the end, we use this specific article published in Wikipedia to make the analysis of the different versions. Rayman is offering a lot of features, it is more newer than others, again, the license is GPL version 2, which is also good to have this version. One of the amazing things is like you can also configure different things and you can connect with Jenkins. There are different notifications interfaces like email, add-on, MPP, which you can use with Pitching, obviously you can do a couple of tweets there. For version control, well, the answer was pretty simple, we use Git, why we use it, because it's a distributed system, it is used by the Linux kernel development, also for OpenStack, it is distributed, it's small, it's fast, it's also a new trend for developers, which is also nice. I am also mentioning that in the version control software, I use Garry, I know that Garry is more for doing reviews and doing basically cover reviews, but something that we discovered once we were working in this thing is like Garry is offering inside of the server Git repository, so for that reason, we consider it as a version of control, so what we did in the community is basically we are replicating the changes from the Garry servers to the GitHub, so for that reason, Garry is here considered like a version of control, even when it is more like a code review system, so again the license for Garry is Apache, well, I mentioned that it has a Git integration, so for different databases, which is nice, well, it's an active community which is doing a lot of changes. The first architecture that I propose for integrate all these components, I could just consider four servers, well, three of them are hosting the different components that I mentioned before, one is for Garry, the second one is for Jenkins and RedMind, and if you notice, just three of them has a floating IP, so that means that they have the ability to external access to the world. The third one only contains a database. I know that this is a poor architecture, but the idea is like this project is start collecting all the good practices and having better distribution and things like that. So, well, all these things are just related with the components, so for the next phase, I consider the way to deploy these things, and the way to deploy these components, I choose the deployment tool, Terraform, the reason that I choose Terraform, basically, it is because Terraform is a cloud-anostic tool, so it's very nice if you have a chance to take a look at Terraform, basically you describe it in a clarity way, like, okay, I want these, these, these, all these things, and Terraform figured out how to deal with the resources, so every time that I have to explain to my colleagues what is Terraform, it is more like having Puppet, but using Puppet in a cloud, so usually in Puppet, you describe what are the things that you want in your server, and in this case, Terraform, you describe the resources that you need for your application, so it's pretty nice. I really like Terraform. So what are the things that you have to do? I try to do simple. There is a couple of external environments, variable environments that you need, obviously the way that you tell Terraform to connect to OpenStack, so all these things are just specific things for, for, for this application, and just simple type Terraform apply, and this is going to connect to your server, and it's going to deploy all these four servers, and it's going to create the security groups, the floor in IPs, the router, the post provisioning, everything. So I will try to do a demo. I know that this sometimes is hard to, to, to do in, in life, but let's see if that works. Hopefully this is big enough to. So basically I'm going to do Terraform run. In this case, it is going to check with my cloud provider, in which in this case it's OSIC, so it's going to check with the OSIC cloud, it's going to check if all the resources has been there, and what is the current status. It's going to try to check what is the difference with the things that I am proposing. If there is a difference, it's going to say, well, in this case, there is no changes, just because I have been deployed those things before, so I'm going to destroy it. Really? Okay, so maybe, maybe if I do it bigger. Well, given that I am destroying the resources that I have there, is waiting for a confirmation, so I'm going to destroy everything from the, from the server, from the cloud. So in this case, it's going to remove all the components. In this case, it's the security groups, the network, the subnet, the floating IPs, all the things that I have, it is going to be destroyed. And what I want to show after the addition of these resources is the way, that is the easy way to deploy all these things. So hopefully this is not going to take too much time. Okay, it's destroying the floating IPs, it's destroying the router in this case. It is almost there, security groups. So which is nice, it's also following the cloud computing methodology, like that you, you only use the resources by demand. So basically, your application, you don't need to keep all these things there. You can destroy the resources and basically you are not paying any, any more money to the, to the cloud provider. I promise that it is, it is almost there. I don't know why it's taking a little bit more, oh yeah, there is it. So for now, I don't have any resources. Just the only thing that I want to show here is, like, how easy is to, to deploy this development infrastructure. So again, is using Terraform, apply. And that's it. That's the only thing that you have to, to type. In this case, is it is going to tell you all the, the details of your application. So something that we can take a look. I just want to just look, work through the source code here. A little bit of the, the files that are deployed there is a couple of Terraform files. The only thing that you have to modify in this case is the variable stuff where it contains all the details that are used for your cloud provider. In this case, obviously from different cloud providers, they are using different flavors or different images. The external category is completely different. So it is something that you have to consider for, for, for your deployment. Obviously the passwords are here, so it is not too much secure. But anyway, at the end, if I am looking at the, well, at the end, once that everything has been provisioned, the output, it is showing the floating IPs that you can use to connect your, your services. Unfortunately, the last images used in, in this specific cloud provider, it is having some issues, so I am sure that it, I am not able to access to them, but my initial test, it was working. So it is something I need to figure out later. So continuing with the demo. So try to see if there is a way to, okay. So going back to the demo, oops, yep, sorry. Well, that was the demo. I have a couple of future plans for this specific project. One of the things you notice, this is a, this has a poor architecture. Obviously, it, it requires a lot of things to do there. We need to add a couple of load balancers, clusters, make more resilient application. The security improvements, again, I am just using plain text, so maybe it would be nice to increase the passwords to do better distributed way to, to maybe also distributing the, the networks and that way also improve the security stuff. Talking about cloud providers, given that Terraform is used, is able to communicate with different cloud providers. It would be nice if this can be tested in AWS or, I don't know, Google Compute. And the last thing is a mutable server. For this case, it's the same pattern that Metric Flower exposed. Basically, instead of deploying an instance and after the installation, you modify that instance, installing new things, the idea is like having an image for every single service. So, so in that way, the only thing that you have to take care of there, the installation, is just the configuration fast of all these things. So, basically, it's all that I have. All these changes has been submitted to one of the internal OpenStack projects, in these cases. OS or PTS tools contribute. The changes are there. You can go there and you can use it and modify, including things. Actually, this is more a call for action. It would be nice if you share your experiences, share something in common, and maybe do it more better. I know that a lot of people will benefit of those tools. So, please contribute these things and share your experiences. It's basically all that I have. I don't know if you have questions or comments or suggestions. All of these things are welcome. This is described by my company. Well, this is the link. If there is no other question, thanks a lot for attending the session and I want to say...