 Okay, good afternoon everybody, my name is Chris Hodge and I work for the OpenStack Foundation. And thanks for coming to this lunchtime talk about User Fundamentals 3, and so Shade and OpenStack SDK. Now if you were here a few days ago, I gave a talk on the fundamentals one into an introduction to the Horizon Web Client to OpenStack and an introduction to the command line OpenStack Client. And so this is a follow on to that, it's just going to be, the intention of this talk is for you to walk away with the tools to be able to go and find Shade, install it, and start using it. It's just going to be a demonstration of a very basic example of starting up a virtual machine inside of a couple OpenStack Clouds. But you should be able to walk away with the tools to look at the Shade SDK and start doing some programming against your OpenStack Clouds on your own. So with that, let's get started. So if you've been watching the keynotes, one thing that Jonathan and Mark kept saying is that we're talking about programmable infrastructure. And so in my previous talks, we were using two strongly interactive clients. But we keep talking about infrastructure as programmable infrastructure, software to find infrastructure. And so that's a key aspect of this, programmable infrastructure is programmable. So simple things should be simple. We've been doing virtualization in cloud environments for enough time now that this should actually be a pretty simple task and we should be able to accomplish it without too much trouble. And so the intention of Shade is to make these simple things simple. So Shade is a simple client library for interacting with OpenStack Clouds. And I want you to notice the plural on Clouds there. Shade is also designed to interact not just with one cloud but many clouds, allowing you to have a multi-cloud infrastructure, whether that be a mixture of public clouds and private clouds or a number of private clouds that you have internally or just a bunch of public clouds. And that sounds amazing. Tell me more, you say. So the way that you start by using Shade is you have to get it. You have to install it into your development environment. Shade is a Python library. So it's a simple PIP install Shade. Now, you may want to install it into your own virtual environment. But Shade is a publicly available library. You can PIP install it and you'll have it immediately available for your programming environment. But to get working with Shade, you also need a cloud. You want a cloud? I can get you a cloud. So there are a number of different public and private clouds. And we have these listed in the OpenStack Marketplace. It's at openstack.org slash marketplace. And there you can browse a large variety of providers who are able to give you both public clouds. And so you can just show up with a credit card, swipe it, and you can have access immediately. Private clouds, if you are a larger organization and are looking for someone to manage your infrastructure onsite or offsite. And also a number of distributions to kind of roll your own. But if you're just getting started with something and you don't want to go and swipe a credit card on a public cloud, you can also do a local installation of OpenStack. There are a number of different ways that you can do it. But I have a GitHub project up in my personal namespace that was built off of some work by Dan Raid as at Red Hat, called Getting Started with OpenStack. And if you have Vega installed on your system, whether that be Linux or OS X or Windows, along with a hypervisor, like so on Linux, say Libvert and KVM or VirtualBox or VMware on Windows or Macintosh. Then with one command, you should be able to stand up in all in one environment. Keep in mind that the environment is very constrained, but it should give you an idea of how OpenStack looks, how it works, and what it looks like. So once you have your cloud, you need to define how your software is going to interact with that cloud. And Shade, by default, will look into this directory. Your home directory.config slash OpenStack slash clouds.yaml. Later on in the talk, after we go through the slides, we'll actually take a look at a clouds.yaml that I have in my environment that is interacting with both a public cloud and a private cloud. But this is the basic information that's going to be in it. It's a YAML file, and so at the top level, you just define a set of clouds. Below that, you then list all of your clouds that you're going to be using. So you give it some name, you give it some authentication credentials, like a URL it's going to reach into, a username, a password, and a project name, as well as a region name. OpenStack clouds typically have regions available, and so if you're in a multi-region environment, you need to set this. Now one thing that's nice about Shade is if you're using public clouds, it actually knows a lot about your public clouds. And so while you can create this file, you can also dig into the docs and you can see how you can just specify a cloud by name, provide some authentication, provide your username and password. And Shade will automatically know a lot of the settings as to how that cloud behaves. One thing that Shade tries to does is abstract the differences away between the different implementations of clouds. So there are some clouds that might provide public IPs through direct IP attachment, and there are some that provide IPs through floating IPs. When you define your cloud, you can specify what type of cloud it is that does that, and then Shade will handle all the details through the same API. So with clouds.yaml created, let's start going through our first program. This is just going to be a very simple program, similar to what you might look at, what you might do if you're interacting directly with the command line clients. But it's a nice illustration of how simple the library is. So this is a Python program, and we start by importing the Shade library. We turn simple logging off. You can turn that on to true if you'd like to see lots of other messages about what's happening behind the scenes on your cloud, what's happening with the client. For now, we're going to leave that off. And then the first thing you do is you create a connection to your cloud. In this case, we call OpenStackCloud, which is part of the Shade library, and give it a cloud name of local. This is the name, if you remember in our previous slide, the different clouds that we had, the different name clouds that we had. This name refers to an entry in that list. So we can start off by seeing what images are available to us. So on that connection, we'll call list images. It's pretty straightforward. All of the CRUD operations that you would expect to interact with on a cloud are generally there in Shade as a direct call. Again, Shade is trying to be a simple interface and make simple things simple. And then in this case, we're just going to loop through those images and print all of them out. The next part of our code is we're going to take a look at the flavors. So again, we're just looking at the resources that are available. And what we're doing right now is we're collecting information about what's available on the cloud, so that we can then take that information and boot our first instance. So we're going through the flavors, we have the connection list the flavors, and then we print them all out. So with that information, you can Shade understands resources in a number of ways. OpenStack Clouds often have two ways of identifying things. Buy an ID and buy a name. An ID will always be unique, but it's also complicated and it changes from cloud to cloud. You could also identify something by name. But the one caveat with that is OpenStack Clouds, many objects may have the same name. And so if you find yourself in a situation where you get an error because the name is ambiguous, then you might have to fall back to using an ID. But in this instance, we're just going to be accessing the resources through direct names. So we set an image ID to seros and then we call a connection to get an image to make sure that image is there. So in the previous case, we were getting all of the images. In this case, we're just getting one image. Same for our flavor ID. We're setting the flavor ID to a name. We're using the connection to get that flavor, and then we're printing that flavor out. No, a name, there can be name collision within a domain. Yeah, yeah, pretty much all resources in OpenStack can have multiple names associated with them. That multiple resources can have the same name associated with them. The only guarantee of unique identifiers is in the identifier. So finally we get to the heart of this simple program to create an instance. We have an instance name that we're gonna call shade test. And then we call the create server command on our connection. So the wait set to true means that we want this to be a synchronous command. And so we are gonna wait until the cloud is up before the command returns. You can also make asynchronous calls. We're setting it to try to attach an public IP automatically. In some instances, you're gonna need to specify a network. Now, if you have, these are parameters that you can set inside of your cloud config file. And so if you do that, the network may not be necessary. But in this instance, it's nice to see that, okay, we're gonna attach the network to the private network. Also, we're addressing it by name rather than by ID, but ID or name will work in both cases. Finally, we assign the instance name, the image, and the flavor ID. Once this call returns, we can print information about the instance to see what state it's in. So that's our program. And let's switch over to our command line environment and see some of these in practice. So right now, I have two clouds running. I have a vexhost public cloud, and I have a private cloud running on my laptop. If you're here a few days ago, you remember the private cloud didn't work. I think we're gonna see it work this time. I'm hoping, keep my fingers crossed. So first of all, let's take a look at the clouds.yaml file. So you can see in my definition here, I've specified my clouds. I've named two clouds, one public and one local. Provide the authentication parameters for them and the region parameters. Now, this is a copy of the file with the passwords changed, because this is going on YouTube and I don't want to expose my credentials to the world. But within the cloud's file, we have our password set on this and the connection should be good. And then we take a look at, this is just the exact program that we ran before. So let's take a look on our private cloud first. So I'm just gonna copy these commands over from this program into a REPL just so that we can be a little more interactive with it. So we import shade, we set our simple logging defaults, and we create a connection. And we're already there. Now let's, so we call images, connection.listimages. We didn't get any errors back. That's good, it means that our connection was good. And then for image and images, we print image. And there, we see that there's only one image in our system. Now, if we change our connection, so we'll call it connection2. And then we do the same calls, images is equal to connection2.listimages. And then for image and images, print image. We see that there are many more images in here, and the call is pretty fast. Okay, so let's continue. We're gonna do the same thing for the flavors. We see a number of flavors that are listed there, including the M1 tiny that we named before. But we can make this, now we will make sure the seros image is there. You remember our script, we wanted to call the seros by name. So the nice thing about this is you can actually, in an environment like this, if you make this call and the image doesn't exist, shade will throw an error. So let's give it an image ID of bogus, and it's none, right? So it didn't actually throw an error, it couldn't find the image, couldn't find it in that set, and it returned the empty set. Okay, so let's get back to our original image, same with our flavor. Let's check the existence of our flavor here. Our M1 tiny flavor exists, and we're gonna build our first instance. Give it an instance name, shade test, a network ID of private, and then the connection blocks, while we create the server. And if we switch over to our private cloud, our local installation, when we look at our instances, we can see that there's an active cloud called shade test. So we've done that there. So let's look at our vexhost cloud, let's log into that. If we look at our running instances, we see that there aren't any running right now. So let's do the same thing on the vexhost cloud, we'll watch this come up. So instead of going through all of the same things that we did before, we'll just do a, so we're using the same instance name. So we'll call it testing instance two, connection two dot create server. Did I call it connection one? We make the call, and we're missing an image attribute. What did we miss on that? So it looks like it wants to have the, I know what it is. Remember, I used the same image ID on the previous one, but there's actually different images in the vexhost cloud. So we need to change the image name. So we actually need to change our image ID. In this cloud, we called it seros one and our flavor ID. In this case, it's a v1 standard one. Let's try the same command again. It's a asynchronous call. If we go to our dashboard, we can see that the image is being created. One of the things to note here too is, it's done all of the work to create and attach a public IP address. Remember when we asked that the IP be auto-allocated? The same thing here too. This cloud uses floating IPs, vexhost uses direct attachments. But I never asked for, I never had to issue any commands to say create a floating IP and attach it. Shade just did the work that it needed to do to be able to get me an instance on the public network, okay? And you can print information about this. All sorts of information about the cloud, what its power state is, what its IDs are, any attachments might have to it. And you can actually perform operations directly on the system, instance. So Shade gives you a completely programmable interface to your OpenStack clouds. So that was just kind of a quick overview of just very simple program to allow you to use Shade to interact with OpenStack on two different clouds. So the original steps of this were actually taken from a first app tutorial that's available within the OpenStack documentation site. If you head over to developer.openstack.org slash firstapp-shade. You can follow along and write your own first application. The directions there are much more extensive, go into much more detail and actually have you building a working multi-instance distributed computation application, so it's pretty neat. You can also see the Shade documentation, it's also extensive. You can find out about all of the features that are available, the assumptions that Shade makes. You don't really kind of dig into using it to build applications. That's at docs.openstack.org slash developer slash Shade. Thanks everybody and have a good time with OpenStack. Are there any questions? Okay, so the question is, is what's the range of OpenStack releases that Shade handles? As far as I know, it goes back pretty far. Shade is trying to use, so there are a few, I would guess back to Liberty. I don't know if there's an, I don't know the exact answer to it. But one feature of the OpenStack community is that once we create an API, we try to keep that API and make it stable for the lifetime of the project. And so when we make a decision about the API, if you're upgrading clouds, software written against a new cloud should still work against an old cloud and vice versa. So you're more likely to have software written against an old cloud work against a new cloud because there may be new features you're taking advantage of. But I don't know the exact answer to that. But I know that compatibility across releases is a core value that our developer community has. In some cases, Shade is using the OpenStack client. But I think Shade is also starting to build out its own interfaces, direct REST API interface calls. I don't think so, no. So the question is, does this fit into your tool box in a way that Terraform might? The answer is no. Shade is an OpenStack specific library. So we're Terraform is meant to be applied towards a number of different clouds. So yeah, so it would be more if you're directly targeting OpenStack installations. So the question is, what APIs are available within Shade? So on Shade's documentation, they have a full list of the data models they support. And so it, yeah, stacks are in there. So they do support heat templates. And as time goes on, more and more OpenStack compute models are being integrated into Shade. So the question is, are containers also supported? And yeah, under the Magnum service, they are. Yeah, yeah, so Magnum is the container orchestration service. So there's support for that. There's also a fairly new project in the OpenStack ecosystem called Zoom, which is direct container creation. So it's essentially, you create a single container rather than pods of containers like Magnum does. There's no support for Zoom yet, but that's because it's a very young project. Any other questions? Thanks for your time.