 Next talk in the session will be about building your first OpenStack application with OpenStack Python SDK. Ladies and gentlemen, please welcome our next speaker, Victoria Martinez de la Provence. This is building your first OpenStack application with the OpenStack Python SDK. It says a few heads up. This is not a training. I know that the title could be a little confusing but this presentation has been going through a lot of changes in the time in which I started checking out the tools that we already have and the latest updates within the OpenStack community with regards to this topic. So this is not going to be a training but an overview of what we have currently in OpenStack community for building applications on top of OpenStack. And so this is not a deep dive of the OpenStack Python SDK. We are just going to see how to use it but we are not going. So I don't want to bore you with the internals of code. It's implemented. I don't make sense for me so I don't think it's going to make sense for you. So how is it going to be this presentation then? This presentation is going to be free fall in which I'm going to start with a few anecdotes of how was my path on creating, working on building an application of OpenStack. Then we are going to see the tools we have currently in OpenStack community for this purpose and then we are going to finish with a few tips and tricks of building cloud-centric deployments for, well, clouds in general, not only about OpenStack. So I'm Victoria Martínez-Heracruz. I'm software engineer at Rehat. I'm currently working full-time in OpenStack. I'm not what you would say a cloud developer. I don't develop applications to run the cloud but I'm a cloud builder. Another thing about me is that I'm co-founder of the community in Argentina. I'm very proud about this so every time I have the possibility I mention it and it's one of these fabulous opportunities to do that. So here it is. So what is OpenStack? This seems like, okay, you are giving a presentation about OpenStack and I respect the audience to know about this but in previous conference I noticed that there is not a good sense of what it is and what is the current status of that and just between us. The amount of projects that arise in the OpenStack ecosystem is so wide that often we OpenStack developers lose sense of what is there and what is not so it's always good to do an overview of what is the current status of OpenStack but first let's see what is OpenStack in broader terms. So, broader speaking, OpenStack is what you would say an operative system for data centers. More specifically, it provides a set of tools that allow you to handle resources that can be compute, networking and stories, generally speaking, to a single entry point which can be, well in this diagram is the OpenStack dashboard depicted but it can be an interface or a script or whatever. OpenStack started being infrastructure service which the main components in the top of this diagram. We have different kinds of storage, the object storage and the blog storage. We have the identity project, also compute, networking and an image service. And then with time and with the, well, pike office, there has been a lot of new projects that are more like in a higher abstraction level that can be considered to be platform as a service in which we can talk about, for instance, database as a service project, through messaging services, telemetry, big data, share file systems, manila which is the project I'm currently working on, containers, orchestration, very much provisioning, DNS, you name it. There are other projects like this. These are not all but these are the projects that has been in OpenStack ecosystem for a while now and are considered like to be, you know, part of the big trend. So running apps on OpenStack. How it was a few years back at least. Now I'm going to tell you which was my first experience working on building an application to run an OpenStack. This started, this happened on a conference that is called Grace Hopper Celebration. It happened in 2014. We had what it was named the open source day and it was the topic of this open source day was to create, to contribute to projects that had social impact by using open source technologies. It was a really great crew, mostly people from rack space, and they invited me to be a guy for that workshop. Honestly it was like, okay, I have no idea about this, honestly, but it sounds like a great idea, so why are you going to say no? So I say yes, and I started looking into what was going to be done in that workshop. And well, when they started telling me what was the idea of this, they told me that we were going to leverage the scalability and resiliency that OpenStack as a platform has to cover situations in which there are need or desofters. For that we pick an application. We did a lot of research on one of the applications that caught our attention, which is a tool that allows you to gather, to collect data, and to display it in a way that allows us to react to those events in a more organized way. This application is open source, is great in PHP. That is not the best part of it, but the whole idea of the application is awesome, and we decided to deploy that application. For that we have to, you know, since this application was not intended to be run on a cloud, it wasn't an application, it's generally like any other else, right? We had to define a cloud-ready architecture for it, and the key of this was to be able to deploy this application in a way that was fast and that required no integration from us. That was writing a script to automatize that, right? So in preparation for this, since I was going to attend to this workshop, and it was like, okay, I have no ideas, I have to get ready for this. I tried to, you know, define an architecture for it like the simplest one. I came to this architecture that is depicted in this diagram. It is pretty simple as you see. It's just two web servers with running the application. One dv and one load balancer on the other end. So it's HA and can react to changes. And, okay, once I have this diagram done, it was like, okay, so now with the tools that we have in the community, how are we going to automate this? How are we going to write this script? And, of course, I ended up looking at the open-stack Python clients. Each of those projects I show in one of the first slides have a client. And it sounded to be like the most natural way of building my application in this case. But that started to lose sense pretty quickly. And let me show you just one example. Usually when you are building an application, you know, to perform, you know, trivial operations like create a server, delete a server, list servers, you know, to access to them, to launch them, to install things on them. This is an example of the least common for the Nova client. As you can see, instantiating the client is pretty straightforward. You just pass the user's password and the offer and the process you are working on. You can list the servers that way. It's pretty straightforward and you access the resources, sorry, the attributes of your resources through a dot-call. That's pretty normal. But now let's go and see, okay, I want an image for this server and go to launch, right? So let's see how glance managed this operation. You can see already that instantiating the client has a different signature. It has less parameters, right? You don't have the user and password there. You only have a token and now a URL. And when you are listing the images, okay, you access them the same way, but then you are handling a dictionary. Just to add more to this example, let's take a look on how Swift handle this operation. The connection is like a merger between the two we saw previously. Then we have to access to the container for Swift in this strange way that is get account. We don't know what we are doing that. So it's like we get the containers and we access them through a dictionary. Okay. I've been a software engineer working full-time. Open stock is like, okay, it is weird, but whatever. But someone that is, you know, trying to use the cloud and have everything working, like don't partner with the syntax, right? Ended up like this. This is the, you know, graphically visualization of how a probably cloud developer would end when trying to deploy their applications in the open stack. So this is certainly a problem. It is not, the thing is like there is a misconception of how people usually take the Python clients. This actually is fine that it happens because the clients were intended officially to create the command line interface we use for open stack. It's not, when they were developed, they were not intended for the users to use it, right? So this is okay. It's how to be, it's how we expect it to be. But of course, so if there is okay, then there is something missing. How are users supposed to interact with the cloud in the whole concept of the cloud in an easy way? So just to end up the anecdote of the race hopper celebration experience and everything, we ended up using, well, the diagram I show, we follow the same architecture, but we ended up using a library that is called Apache Leap Cloud, which I'm going to mention, I'm going to talk a bit more about that in the upcoming slides. So everything was perfect. We have all the applications going on and it was an amazing experience. And it led me, you know, the feeling that there was something to do on the open stack development area, right? So now let's talk about the libraries and SDKs we have currently on the open stack ecosystem that you can use, of course, based in Python. There are SDKs and libraries for a lot of languages. If you check it out, the, well, the wiki page that we have in open stack, at least all of them, you are going to see that there are a lot, several alternatives for different languages and it looks like a mess. But for the Python ones, let's take a look at the ones that I think is worth mentioning. So why we need libraries, why we need SDKs? As I mentioned, there is no way, like, there is no simple straightforward way to interact with an open stack cloud. So because we have a lot of services, we have one library per services, and we have, for each one of the libraries, a different user experience. So imagine that a lot of libraries and user experiences is painful for developers. So in Python, we have these three options. Let's start with this one, the one we use for the grace hopper celebration. It offers you an unified API. The good thing about this library in particular is that it allows you to talk to different clouds. It doesn't, it's not only for open stack, but allows you to talk with, I don't know, different implementations for open stack clouds. It allows you to interact with Amazon, with Azure, and you name it, there are a lot of clouds that allows you, that has plugins for Apache live cloud. The only thing is that, of course, this is not a tool that is being developed by the open stack community, it's third party. But it's worth looking at. Here is a sample of how creating a server for open stack would look like using this library. As you can see, it's pretty clear what it's doing, what is happening there. You simply talk the, take the plugin for open stack that you have for live cloud. You instantiate that client. You basically get a size for the server you are launching, an image that we want to use for that server. Simply with driver create node, with that information you gather for the cloud you have, you have your node running and working. Now, open stack shape. Open stack shape is a project that is a library to interact with open stack clouds that have been born under the open stack infrastructure project. The infrastructure of open stack is the project that is taking care of all the handling, all the processes and systems that take care of everything that happens on the open stack community. So it's a tool that was born to be used internally, right? It is not the case nowadays, of course, that no, there are application developers using this tool. And the main, the key word for, probably, but describe this tool the best is simplicity. The idea is that you get your access, your resources in a very simple way. This is awesome, right? But the only downside you have with this is that you don't have, you know, a finer grain control of what you are doing. If your architecture is slightly complex, then you cannot use this tool for deploy your application, right? Just a red flag here. This library is under development. It's expect to change a lot. The current version of it is going, well, I want to put this right there. You can use it, but please don't use it in production. Just that. So let's see an example of how landing a server and using this tool is going to be very similar to what we saw for the cloud. We simply create connection to the open stack cloud. We can gather an image from your file system in that way. You get the size for your server, very simply with, well, get flavor background, for instance. And then you create your server, passing those parameters, and then you are ready to go. And finally, the open stack Python SDK. Let's make a stop here for a moment and talk about the difference of why we mentioned the former tool where libraries, and this is an SDK. So the SDK, you are able, you are offered a complete set of libraries, tools, documentation, examples that are, you know, jargon free. You are not going to see Nova or Keystone or any of the names we use within open stack for you to manage your cloud. It is, you don't have to have knowledge of what's going on there. You simply say, okay, give me a server, give me an image, wherever. And you have a lot of examples to cover that. An SDK is much more complete than a library. This SDK is aimed for all type of users, users of open stack clouds, consumers of open stack clouds, that is you probably, operators of open stack clouds and developers of open stack projects like me. The idea is that you install ones and you can run anywhere in any open stack cloud implementation you have. So why I choose this tool among the three that we just mentioned. So, well, Apache live cloud, of course, I rather talk about tools that we are developing in open stack communities. So, of course, I rather to say with shade or open stack SDK. And in the case of shade, it was like, okay, this, it was a tool that was being used for internal purposes. So if there is something that is more targeted to what we are talking today is the open stack by the SDK. It's a very valuable use case that we are talking about. And whereas it's under development as well as trade, I think this project requires a lot more attention and a lot more of, you know, spreading the voice and showing how it's supposed to be used. So, this SDK is already on PyPy, so basically you pip install open stack SDK and you have it there for you. As mentioned, it allows you to write automation scripts that allow you to create and manage resources in any open stack cloud. Now, let's stop for a moment and talk about how is this SDK structure, what are you going to find when you interact with this SDK. Basically, it has been structuring a two-layer approach in which you have a connection interface and a resource interface. The connection interface is the one that you as an open stack cloud consumer are going to use. It allows you to access to your session authentication transfer and profile through two classes. One is the connection and one is the profile. And the resource layer, you are not supposed to use it, but it is there. You can access it. So, if you have needs to have a more fine-grained control over what you are handling, it is more aimed to be used by, I guess, open stack developers if they want to do something fancy or whatever. But resource layer take connection objects and it's not what you want to do. So, you are going to stick with the connection interface and with the classes that the connection interface provides. So, how is to create a connection with a cloud? It's for any cloud you have, it's going to be the same. You are going to instantiate your connection in this fashion in which you have the alpha URL, where you have your authentication, person name, user name, password. You can interact with all the services in your cloud just by this connection. Then, in order to create a server, well, I added a few more steps here. But, basically, you would need an image in which your server is going to use. Flavor, which is the size of the instance you are launching. A network, if you already defined it, but it will require another snippet of code to do that. And a keeper to access your server. Then, you simply specify, okay, compute clear server and you should be good with that. Another example is creating a keeper, as mentioned in the previous slide, for access to your instance. Here, I'm showing you how, if you have a keeper already in your cloud, you can find it by name. Or, if you don't have it, you can grab it from your local file system and upload it to your cloud in that fashion. There is some extra code that interacts with the operating system I'm using. But, the part of the SDK is a few lines only. And, since it was, like, okay, for the creation, the part of OpenStack is already covered, right? The only thing you need to have is something like the Python OpenStack SDK. But, something that, you know, come to my attention during the app creation workshop was that sometimes developers doesn't have a real understanding on how, how is to create applications or how to take full profit of the cloud infrastructure you have. So, I wanted to bank these appendix in which I want to leave a few guidelines for you for app creation on the cloud. After all, you know, it's sometimes that about the tool, but how you use the tool. So, let's talk about a common classification that has been gaining popularity in the last couple of years, I would say. There is a difference between cloud-ready applications and cloud-centric applications. The cloud-ready ones are the ones that are standard, you know, like Houshahiti in this presentation example, that are cloud-centric because they were not intended to be run on the cloud in the first place, but they can work perfectly when you deploy it in like in a micro-service architecture, and they won't fall short because of that. And cloud-centric are the ones that were born in the cloud, that were intended to work on the cloud. Of course, that may probably most of you will interact with cloud-ready applications not with cloud-centric applications. And whereas you have this cloud-ready application, it doesn't mean that you have to change all the code, you know, to start from scratch with your applications in order to have them running on the cloud. This classification is just so to mention that there is a new trend on cloud-centric applications and that there is a slight difference, but it's not so much. So, one of the probably cornerstones that I heard is that you have to take into account that the topology of your application is going to be dynamic. If your application has to change, it's going to change. It is not like usual, you know, virtualization spaces in which you were used to have, you know, your application all in one with your DV and everything just in one instance and you will take care of it and everything. The environments in the cloud change very dynamically. You are going to destroy and create new instances very frequently and that's the whole point of the cloud computing, right? The idea of having this dynamic topology is that you will be able to scale individual components easier, you will be able to simplify the maintenance and reuse of your applications. You are going to have more fault torrents and one example of how you are going to do this is, for instance, don't hardcore information about networking, delegated to the networking services in the case of OpenStack to Neutron. What else? If you merely storage, don't assume, please, that the storage that you have in your instance is going to be persistent, like, for instance, for all the static and non-stated data you have in your application. For example, your logs, right? When you install your application in your instance, usually you store your logs on their backlog, right? But what happens if that instance fails and goes down and you want to check it out, what happened with application? Then all the logs you have in your system are missing because the familiar storage is, as the word says, ephemeral. So you can use... It's advice for you to use persistent storage solution, like OpenStack, it can be the block storage sender or the object storage sweep. You only have to delegate that task to an external service. What else? Stateless. Stateless or finite storage limits the scalability of an application. If possible, you should be able to omit using... to keep a state. If you can omit it, try to store the station state in a highly available store outside your application. Just as we talk about the static and non-stated data, the same for a state. For instance, you can use database services to spin up DB instances to store all the states of your applications there. Standards. Okay, yes, this is not new probably. This is in general the same for all the applications you are going to develop in your lifetime, right? If you can keep with standards, the better. And of course, in the case of cloud, this is even more important because you are going probably to change environments pretty useful, right? Sorry, pretty frequently. So try to avoid using obscure protocols. If you are going to use, I don't know, a transport protocol, try to keep with it common once with HTTP or whatever. But don't use a protocol that is, you know, corporate just because it looks fancy or it has some features that cause your attention. Try to stick with the standards always. And don't rely on OS specific features. Since the application you are deploying should be able to change. If you need to change and you tie it with specific features of the operative system, then you are going to be tied and you won't be able to pull it to whatever platform you want. For instance, if you are using a new Linux system, try to use post-ex standards and not use an error. And automation. Cloud applications used to be installed frequently are on demand. What does this mean? It seems to be, you know, pretty simple, you know, common. But try to automate the configuration setup. Don't expect a user to be able to, you know, select configuration options or to... I don't want to say the L word, but if they have to sign a license agreement, don't expect them to be able to do so. Deploying an application on a cloud should be automatic. There should be no user interaction when doing this. And also the idea is that you can deploy your applications quickly and, you know, not having to touch anything. So, minimize the dependencies will require in this step. So that was pretty much it. Now I am going to open for Q&A. Any questions? Yes. Great talk. Thank you. Is Ushahidi still running on OpenStack? Or what's kind of been the evolution of that since then? What are the lessons learned that you've made out of, you know, that application and how it's evolved on the cloud? So it was in a public tenant when the public workspace cloud was up. So there is the live cloud scripts available, but I don't think the application is still running. Other questions? Yes. So how does the OpenStack SDK handle the differences between the various public clouds that we have in OpenStack? That's a good question. Compared to Shade and others that are built around that, abstracting that difference, how does it behave? So you can handle the difference between clouds using the profile class within the OpenStack Python SDK. You have to share a YAML file, I think, that has all the differences with it, and you will use it for all the clouds you want to interact with. Other questions? I have a question myself, if I can. Sure. I come from working with public clouds, so this Python SDK, more or less, it's comparable with what BOTO is for AWS, it's the Python interface to Amazon Web Services. Honestly, I haven't put my hands on Amazon, but probably if... Yeah, you can spin up instant tears and configure network. Exactly, yeah. You can interact with the cloud as a whole, and I don't know about BOTO, but in the case of Python OpenStack SDK, you can only interact with OpenStack Cloud. You won't be able to use the Python SDK for OpenStack to interact with Amazon, for instance, in Azure. Thank you. Yes, we have time for other questions. Thank you for the talk. You mentioned pushing State away from the server. It's actually a comment. If anyone here is using Django to build cloud applications, you can use the cookie session store. You've got signed cookies, cryptographically secure, and you can push your session state into the cookies. Therefore, you don't have any session state on your server, and it's built into Django. You can just use that. No state on your server for your sessions. Awesome. It's good to know. I'm going to take a minute just to mention that there is going to be a training on the developing native applications with Shade. It's going to be on Thursday at 2 p.m. at room E, and we are also organizing an OpenStack open space on Wednesday, that is tomorrow afternoon time. We don't know yet the time, but we are in the midst of it. If you are interested, please follow me on Twitter. I'm going to tweet in which time and where we are going to do that.