 Can everyone hear me OK? All right, let's go ahead and get started. So first off, my name is Michael Elder. I am a developer with IBM. And what I'm going to talk to you today is about a project that we've been working on for some months to look at how we enable really sort of DevOps using some of the OpenStack technology. And then what I'm going to talk about is some of the extensions we built into Heat. And then I'll show you some demonstrations of that running as well. So really what I'm talking to you today is about managing change. And I'll sort of use this delta symbol as my symbol of change. But at the end of all of this, it's really just about how we deal with change in a more predictable and reliable fashion. And so what we see with DevOps is this trend of managing risk in a different way. If you roll back maybe a decade, the way to deal with risk was to insert more process and more bureaucracy to ensuring that a problem didn't reoccur. And with DevOps, we see a difference in the way that we approach the problem to actually start thinking about small batch changes and managing risk through more automation and through making smaller and more incremental changes so that if a problem is introduced, it's easier to roll back. And so we see this process applied to applications and we see this focus on improving the life cycle and the delivery timeline of the application itself. And it's putting downward pressure on how quickly the infrastructure can change to meet the needs of that application. And that's really where this concept of software defined environments offers an opportunity to help improve the overall process. And so this line, and I like the term magic line, but I think it's the same concept that was described in the keynote on Monday morning. There's a line between the application and the infrastructure today. And really, I think what we see is that line sort of blurring, the changes becoming themselves smaller and more incremental. And so it's not necessarily application change versus infrastructure change, but simply change. There's been a lot of talks today about heat and about some of the software configuration stuff that Steve and others have done. And they talk about software configuration and orchestration as separate things, which I think makes a lot of sense. But I think over time, as the software defined environment is realized, we'll see those lines continue to blur. So if you haven't heard about OpenStack Heat, then you're probably at the wrong conference. But just a little bit of background, heat provides this way of representing software resources, excuse me, infrastructure resources as a file, as YAML syntax. And so there's been recent support for Chef and Puppet, Shell, and other software configuration hooks. What I'll show you today is work that was begun after the Hong Kong summit, but before the final implementation of Icehouse would look a little bit different. But in spirit, it's a lot of the same capability. And what I'll show you is really using HOT to describe these concepts both at the infrastructure layer and at the application layer. And one of the neat things here is that heat already supports not just the notion of provisioning an environment, but also updating an environment in place. And I think that's important not only for the infrastructure, but obviously at the application layer as well. And so let's talk for a minute about software defined landscapes. When we think about the roles involved, and I try to keep these as whiteboard friendly as possible, but really this concept of developers, integrators, and specialists working together, every customer that I talk to has a different label for these various roles. No one calls the IT specialists the same thing in every shop, no one calls the solution architect or the technical project lead or whatever it is. So I just kind of group them into specialists which have deep knowledge and integrators that have broad knowledge. But ultimately you get these sort of roles on the left, and we get these sort of layers and artifacts on the right, which all have slightly different characteristics to them. And so what we see again is this notion of kind of converting and breaking down that line and that division by capturing the entire application stack in one document. And this is where the heat orchestration template language can help, because it already provides a way to capture your infrastructure resources, your compute, network, and storage. It recently has inherited the ability to do software configuration for Chef and Puppet and Shell, along with the extensibility for other hooks and other capabilities. What I'll show you is what we're doing with some of our DevOps tooling at IBM on top of this platform. Once you have everything represented in one template, it gives you some interesting capabilities. Now I can think about each environment as simply the same template but perhaps some different parameterization. It's the same overall abstract structure, but I change the number of nodes in my cluster. I change the size of the VMs or the compute nodes that I want provision for dev versus QA of production. And so that means that now this artifact, this blueprint for your infrastructure, for your entire full stack app, becomes itself part of that delivery life cycle. It becomes something that's promoted from one environment to the next. Because again, we can do this update behavior in place. Not only can we use it to prime new projects and to start new activities, but also to update those existing environments in place. And that's a really powerful capability here. So again, we get this notion of software defined delivery. These are files, so I can version them like I can any other artifacts along the path. I can apply them over and over again. So as I iterate on the infrastructure itself, I'm actually making changes to a file. Same processes that I use for software that have been developed with Agile over the last decade can be applied to managing these artifacts as well. And that means because I can spin things up more quickly, I can validate them. In fact, the talk that was in this room previously from Rackspace talked about their kitchen sink template, which I thought was a good term for it, where they basically have every resource that they want against heat and they provision it to make sure it's working OK. You can apply the same technique to your applications that they have for the heat engine. They're verifying the heat engine functionality. You can actually be verifying your application's functionality and making sure that for every new build of the application, or for every new change to the networking, every new change to a new image that's being adopted, is actually being tested and verified much earlier before it gets to production. And then because we can provision the entire thing, we can update those existing environments so we can spin up and verify new stacks in place before we promote them forward. Portability becomes an important aspect here because it's not just about creating an artifact to maintain one environment like development or QA. It's about creating an artifact that becomes part of the overall lifecycle from beginning to production. And so heat already affords the opportunity to break out configuration files. In heat terminology, they refer to them as environment files. I tend to avoid that term because I think it creates confusion. I'll just call them configuration files, just to be generic here. But what's neat is that we can externalize the parameters for dev or for QA or for production, but again, keep that overall structure, that consistency of the template and of the architecture for each of those various phases of the lifecycle. What we'll show at the very end is actually this notion of how we can overlay some concepts onto those templates to not only make them portable between multiple environments running OpenStack, but even between different kinds of cloud, whether it be Amazon, VMware, Rackspace, or OpenStack. And we'll talk about some of the reasons why we might want to do that. And we'll show how that can actually enable having this sort of competing paradox of a portable document that works against different kinds of clouds, but within a particular cloud is optimized for the capabilities in that cloud experience. So all this is really just kind of the background, the conceptual understanding of software defined landscapes, being able to capture these blueprints, being able to describe the entire stack, update them in place. What we've done is kind of turn that into a new way to think about creating this infrastructure by defining an extension on top of OpenStack. I say extension. I'll call it an experiment for now. What I'll show you is actually some content that is not yet released, but is something we're working on. So for now, consider it an experiment. But I'll show you what we've done with this. What you're looking at is a web-based interface for hot. On the right side, we have a palette. We'll see some more of that in just a moment. In the middle, we have this editor. We can represent both diagram and textual views. On the left, we have a simple file-based navigation scheme built around blueprints and configuration. And we'll see that in the demo as well. One of the things we're experimenting with is this notion of specialist integrators and consumers customizing the interface based on their role, because we find that there are different sort of entities and, what's what I'm looking for, really sort of political entities. Political interests within an organization. Some of them want to empower developers. Some of them want to enable them, but make sure they don't tear everything up. And so we see different consumers that we've talked to about this technology. Some of them like the idea that a developer gets in and creates these editing experiences, creates these templates. Some of them don't. And so that's where we think we may end up customizing for that consumer role, maybe not exposing the editor, maybe just exposing kind of a catalog of available templates. But we'll see more of that going forward. One of the important things about this, so a little bit of background, in my field I've been doing design of topologies for some time, back to even 2004, when we looked at it from the perspective of an architect and creating architectural diagrams of a topology. Actually, within Rational Software Architect, which is an existing product, we can model out in very fine grain detail the entire configuration of the application. But around 2008, 2009, 2010, we saw this pivot where the role shifted from architects trying to understand their configuration to this new idea of an infrastructure engineer or of a script engineer, the DevOps engineer, beginning to take more control of the entire stack and understanding each of the different pieces. And what happened with what we were doing is that we began to see this impedance between the diagrams that were created and the roles who traditionally like text editors, that like VI, that like Nano, that like whatever their favorite editor is, even Eclipse. And so one of the key things that we did with this approach was to make sure that we kept the text of the heat document front and center, but provide this fluid experience where you can move back and forth between them very quickly and very easily. And so as I go through the demo, you'll see that things like the selection of the object I'm editing are kept consistent as I flip between diagram and source views. I can drag and drop into both the diagram and the source editor. I get validation feedback in both UIs. And so what you get then is that the design becomes sort of a map. It's a way to understand, and more complicated to apologize, how things interrelate, provide a visual understanding of it. But you can always drill down immediately into the text to change that little archaic setting that doesn't really make sense being shown in the diagram. As you saw in the palette, we actually talked to not just the heat API, but also to Nova, to Neutron, and to Sender. So we pull data from their REST API and incorporate it into the palette so that we can use those building blocks in our heat template. So I don't know if you've built a heat template before, but the first couple of times that I did it coming at it as a new user, I get lost in trying to track down all of the different IDs that I need. The network ID that I'm attaching to, the image ID that I want to reference. OK, now I'm going to a different open-sack instance because we're still dealing with toy clouds in our dev environment. And now I need to change the ID for that. And this actually makes it a lot easier, because now I simply drag and drop all of the details about that object I brought along for the ride. And it also makes it easy to parameterize them into configuration files if I want to change them for each deployment. And as I've alluded to, software configuration becomes part of this experience. So it's not just about defining the software infrastructure, but also understanding software components. I'll talk a little bit about the history at the end if I can contain the time. I want to save some of the time for the demo. But suffice to say that this will look familiar to what's in heat today. But it was actually derived off of some of the thought that was at the Hong Kong Summit and some of the material that was there. So it looks a little bit different than what's in Icehouse. But conceptually, we still have a software configuration. And we bind it to servers via a software deployment. But in our case, we've made it aware of our Urban Code deploy product for DevOps. Over time, we'll see Chef and Puppet and other resources appear in this palette, but we just weren't able to contain it for today. We also tap into Keystone for Identity. So when I log into this editor, I'm actually logging in directly to Keystone as a service, getting the tokens that are required, and then giving basically Landscaper, which is our internal code name that's not a marketing name, get attached to Landscaper. And it talks to Nova, Cinder, and Neutron on my behalf using that authorization and token. So different users, based on their tenant membership, based on their permissions, will see different content in their palettes. One other small item here to note, we can actually override the orchestration engine. And part of that's just based on how we do development, where we have multiple heat engines that we're changing over time. But I don't expect that to be as common a feature going forward. So let's actually see some of this in action. So I'll switch over here. Hopefully the network is friendly with me today. So can everyone see this OK? Is it large enough? Make it a little bit larger. So what we're looking at is the web-based editor for Landscaper. I have a simple list of available blueprints and environments. We'll take a look by starting with the blueprints first. So again, we try to keep this notion of files front and center. Try not to hide or inhibit you from getting access to your heat templates very quickly. And in fact, over time, we're going to do some interesting things with how we expose these directly through the web UI using SCM protocols like GET. So that will enable you to actually deal with versioning in a more predictable fashion going forward. But again, I have a concept here of the network that I brought over from the palette earlier, a Nova compute node that's referencing an image, a software component. We also have some icons here to talk about storage. So here I'm attaching a couple of volumes to this, actually one volume with two gigabytes of data to this node, security groups and elastic IPs. So again, the diagram gives you that bird's eye view of what's available and how it fits together. And then I can switch into my source view. Notice that since I had the components selected, it automatically put me in at the right place in the editor. Within the editor, we have validation. So if I have a custom type, and the heat engine knows about it, it'll recognize it. But if I had a type that wasn't custom and that wasn't known to heat, we get immediate validation that that's a problem. So again, making it easier to create these things for folks that are maybe newer to the process. That's also true for parameter references, for attribute references, for things like that. We have undo support built directly into the editor. So some of the capabilities you would have with your own native text editor are going to be available here as well. And you also notice the markers down the column. So if I have to-dos in this document, we'll recognize those and insert markers along the gutter there. As well as if I had errors or other problems that I needed to fix or references. So when I pick something like UCD server URL, it's showing me where else in the document that reference actually appears. So again, just trying to make it easier to navigate and manipulate these templates. Over here, you notice that my file browser hit itself and out came the outline view. I can easily get back to files if needed. But within the outline view, all of the resources are available, so I can click around very quickly. All right, so let me actually do a couple of things here. First, I'll show you kind of a larger example. So this is actually, if I picked the right one, yep. So two networks, multiple nodes attached to those different networks, components deployed to each of them. Again, trying to provide that bird's eye view, I can quickly jump in and get to the source if needed. The outline view can help me find things in the document as required. But one of the things we found is that when you work with a diagram, you sometimes like to zoom out. And you'll notice that our labels continue to stay very sort of larger and bold so that you can still make sense of them. That's just, again, just to help make sense of a really large topology diagram. And if I'm in the source view, I can do the same kind of thing. So the editor toolbar remains consistent between the two modes, and we'll do what's appropriate for that. So you'll see that the labels for the top level resources are larger. I can still read them. But things that are less relevant kind of float into the background. And then I can jump back into that full zoom mode. I can also, as you would imagine, I can drag and drop. So if I want to attach another node to that network, I can simply drag it, and it'll appear. I can place software components onto that node. And behind the scenes, all of that configuration is being created in the text editor. You'll notice that it's highlighted in yellow before I actually persist the changes back to the server. The other thing that's nice here is that, again, this notion of source versus diagram is important to us. We can drag and drop directly into the source editor. So if I grab a server, I can drop it in. If I go to my network, which is at the top, and you may notice this is not really standard heat. This is a reference. Because if we put the network in the heat template and say delete, it will go and delete that network. And sometimes that's not what we intend. And so we have this ability to actually drag a network, an existing network, into our template. And we inject a reference. The heat engine will ignore it. But all of the places where we want to reference it, so by its ID or by its name, they have access to that data directly in the template. But what's also neat is that that becomes a target that I can actually drag content onto. As you saw, I pulled the server and the diagram onto the network, and it floated into place. I can actually do the same thing in text. And notice that, for this instance, the port is already configured for me. I can go and find that port. And I can see it's actually attached to this network ID. The network ID is actually set up as a parameter. And if I go and look at that parameter, it'll actually have the default for when I brought this network over originally. Obviously, if I deploy this to a different cloud, I can change that ID very quickly. And then the other thing that's interesting here is something that you wouldn't necessarily do if it were a true diagram, is I can think about commenting infrastructure like I comment code. And so I can pick an element in the diagram. You'll see it graze out. If I go back to my source view, it's actually disabled in the template. So if I'm experimenting and I'm iterating over and over and over, I can take something out and still hold on to it. Because if you've ever written code, sometimes you have this love of code and you just don't want to let it go. So maybe that's true also for infrastructure junkies as well. And then obviously, if I just put my cursor on the row, I can uncomment it very quickly as well. So again, those are just some nice ideas around the editing experience. All right, so let's actually do a provisioning behavior. So in fact, we list the environments that are known to open stack heat. I'm going to switch over and just show that for a moment. So here are the environments that I already have provisioned that I did earlier, actually earlier today. And of course, I can always link back to the template that they came from. This is a capability that's not really built into the engine natively. You can get the JSON payload of the template, but we haven't been able to really find a simple way to get back to the real source of the template. So we adapted a solution for that. All right, so let's do a provisioning behavior. And hopefully everything will go smoothly because we all know the challenges that come along with live demos. So this should be a pretty good example. So we'll label it as such, and we'll click on provision. And so what's going to happen now is it'll actually do validation. Uh-oh, looks like I have a problem. So if I look, it's shown me all of the places in that template where reference was invalid. This is one of the things that killed us as we kind of iterate over and over. I have to deploy it, wait for heat to come back and tell me, nope, that's wrong. And then I work through that process again. With this, we're validating it before we even hit heat to make sure all the references are appropriate. And then we will remember that last validation up until the point when I start switching around. So here we can see all of the same error messages that we saw before. And if I click on them, it'll take me to the specific place in the text where that problem occurred. So obviously invalid ID is not a valid image ID. So let me switch over to a correct example. And so again, we talked about the network, the compute node in this component. What's going to happen when I provision this is a couple of things. So first off, it will actually provision all of the virtual resources. And it's also going to make Urban Code deploy aware of that provision environment so I can manage it in an ongoing basis. And we'll see some of that more here in just a moment. So I'll create example one, we'll call it summit. Notice we could pick a configuration file. This particular template is not set up for one. But all of the values that are known to those various services of Nova, Neutron, Cinder, et cetera, are actually pulled into the dialog as well. So if I forget what the specific name of my key was, I can override that. I can also change, say, the image that I want to be attached. I think I have that exposed here, the image name. So all the available images, I can quickly switch those out, pick the one that I want. Here, I'm just simply going to override the server name. And then we'll click on provision. At this point, it sent the request back to the heat engine. If I go over into Horizon and do a refresh, because I'm probably logged out by now, what we're going to see is that server coming online. So my summit server, as provisioned by that template is now here. Back in Landscaper, again, we'll update our list of environments. We're pulling that directly from heat. And I can click into that. And here, right now, we've just provided a very simple view of the content in there. So this is really sort of a subset of what you might see in Horizon. The server, its IP addresses, the size, the key pair. This example has a storage volume. So we'll see that storage volume that was provisioned. And then the component as well. In addition, it's not enough, again, just to provision the infrastructure. At least our opinion is that what we see customers wanting to do is really to do a full stack application. And we've talked about this, this challenge of software config versus orchestration. And so the way that we deal with that problem is to take some of the existing capability we have around software configuration and continuous delivery and integrated that with heat. And so here, we actually have an application. It has a few components. We have some environments that are deployed. And notice that some of these, it's aware of the fact that it's actually running in the cloud. I'll show you that in just a moment. And then we have this example one summit environment that is exactly linked to that environment provisioned by heat. We actually will configure an agent on that host so we can continually deploy new versions in an ongoing basis. And then we know what components are placed on that host. And what this gives you is initially it'll deploy that version of the component. And you'll be off to the races if I'm sort of priming or sandboxing for a test. But then I can also come back in and deploy new versions in an ongoing basis as well, which is a pretty powerful capability, I think. All right, so that's sort of the basic starting point. I showed the editing. I showed some of the sort of just UI niceties around that. We looked at provisioning. And now let's kind of take a look at where we go from here. So was there anything there that I missed that I wanted to show? Yeah, I think I hit everything there. All right, cool. So Urban Code Deploy is a tool chain around how we take what you create from continuous integration, the artifacts that you produce. And we make it easy to deploy those into different environments, to understand the inventory of those environments, and the promotion process from, say, dev to QA to production. And so what you saw there was I had a full stack application, I provisioned the infrastructure and the components on top of it. And I made it aware in Urban Code Deploy so I could manage it in an ongoing fashion. And the way that we do this is through this new software configuration resource. This right now is a resource type that we've defined internally. We haven't contributed it back. We're still considering whether that makes sense, because it's specific to our product. But in this case, we can see the type IBM Urban Code Software Config UCD. This was modeling, again, the same flow that had been discussed back in January, or I guess back at the Hong Kong Summit. But this actually allows us to link to the component, link to a process to deploy that component, and even set a default version where I could just say latest, and it would pick whatever's available at the time the template was created. So I showed a little bit already of Urban Code Deploy, but it has this notion of an application-centric view. It understands the components that make up a particular application and what environments they're deployed into. It also has rules around how you can promote from one environment to the next. So you can say that in order to enter a particular environment, I must satisfy these conditions. So let's take a look. I'm running out of time just a bit here, but creating an environment for Urban Code Deploy is actually, this is an integration directly from an existing product to heat. And what we'll do is create a new environment and then have access to the same things we saw from Landscape or from the designer tool. And think back to what I said about the roles. Here I'm looking at what a consumer might see versus the designer or the IT specialist who created the template originally. So I'm going to switch back over to Urban Code Deploy. I'll go back to my application. And as a developer, I'm coming in and I need a new environment, but there's lots of different pieces that have to come together in order to create that environment. And here is where I'm linking back into the same templates that I've just been creating a moment ago. I'll pick the same example. I'll give it a name, dev01, or 03, excuse me. And we'll hit Next. So here we'll start to expose different versions of those templates, so it's not just provisioning at the first time, but also updating it. We'll see that in a moment. But again, I could embed a configuration file. I'm going to show that in the very last demo. But if I want to change properties, we're continuing to use the OpenSack API to make it easy to select the image or the flavor or the key or the public network that you want to attach to. And again, I'm just going to change the server name to give it a non-default name here. And we'll click Create. So the same basic flow is occurring that we saw before. Except now it's coming from a different roles perspective. As a developer or a tester who needed a running system, I didn't have to go in and understand any part of the template. All I saw was the set of parameters required up front. But this still gets provisioned through Heat. And I can go back as a designer and see dev03 pop up. The resources appear as they would before. So I have an instance with a set of IP addresses. The agent gets installed, and I can continue to now use that environment in an ongoing basis. I can deploy new components into it very, very quickly. I can pick new versions here. I just have one version in my environment. But I could have many different versions created for every new build that is produced. So again, this is an example of a vendor product actually tying into OpenSack and using that ecosystem to provide more value for our customers today. All right. So switch back over here just for a moment. And so we saw this dialog come up. We changed the parameter. We went ahead and created an entire environment through Heat again. And the other thing actually that I do want to show that I didn't hit here is once I provision it. So if I have dev02 that I provisioned earlier today, I can also update it from a blueprint as well. And so this again gets into that notion of updating the environment in place over time, thinking about the artifact, the blueprint as just another software configuration, another software artifact that's part of my delivery process. So again, a very powerful idea to get you to the point where you're not thinking of infrastructure change is a very large thing. Infrastructure change becomes modifying a file and delivering it into the process. OK. So the last demo that I want to show is looking at how we think about different clouds. So for instance, if you have OpenStack, OpenStack can talk to different layers of virtualization. You can plug in additional drivers and you can get support to talk to KVM and VMware, PowerVM, ZVM, et cetera, excuse me, PowerVC, but several different layers of virtualization. And that's really powerful. And for customers who have chosen OpenStack as their path forward, that gives them an awesome opportunity to normalize all of the different platforms in their organization behind one layer, behind the OpenStack layer. But we continue to see adopters or customers that either aren't ready to adopt OpenStack yet, haven't made a decision, or have made a different decision. And we want to still enable them to get value from what we're doing around DevOps and around continuous delivery. And what we looked at was how do we take the value that we see in the heat orchestration engine and enable it for other clouds? Obviously, we could continue to write drivers for OpenStack, but that puts an operational characteristic or pain that has to be satisfied in order for that customer to see that value. And so our approach was to try to go as minimal as we could and actually extend the resources in heat, just like we did for software configuration, to support other types of clouds. But we wanted to do it in a way that actually enabled us to create one template that worked in many different clouds without breaking OpenStack. And when we looked at different models, we've been in the tools business for a while. So I worked on Rational Application Developer a decade or so ago. And if you look at J2E, you have models that have WebXML and then vendor-specific side files. And they become a nightmare to manage. It produces this concept that Ben Christensen at Netflix calls friction. If you have separate files that are kind of related, like JUnit tests, that adds friction and makes it harder to keep that content consistent over time. And so our approach was to do this through decoration. So we actually take a heat template that works against a native OpenStack with all of the common types that you would expect, maybe even with our software configuration extensions. And we add additional properties to it in a way that the heat engine doesn't see them if we're talking to OpenStack. But because of some capabilities that have been added by the heat team, we're able to use the things like the resource registry to take OS Nova server and make it IBM EC2 server, or IBM whatever server, whatever cloud technology that we want to deal with, or another vendor's resource type. And we can rewrite all of those types that are supported in core, supported by a native OpenStack, and make them talk to other clouds in a way that doesn't break it. And so here's a simple example. We'll see the demo here just in a minute, because I do want to get to that. But the key thing is that it's showing OS Neutron Net, OS Neutron Subnet, with some properties from the OpenStack types. But within the metadata, which is a section that the engine won't complain about. In fact, from a Havana to Icehouse, we had to change our approach here a little bit. But the key idea is that these additional EC2 properties are ignored by the OpenStack types. So I can provision this against heat, against OpenStack, works perfectly. But then if I go to provision against Amazon, we use the resource registry to rewrite or to change the types that are used for provisioning. And so let's see that actually in action here. So I'll go back to Landscape, or I'll go back to the Blueprints. And here I have my network example. This has a network, a subnet, a router, a gateway, and one instance just to make sure we can get an IP address. And you'll see the same thing we saw in the picture a moment ago. Additional properties that sit alongside the core properties, both for the server, for the network, for the router, for the gateway, et cetera. Now separately from this, we also have configuration files. So OpenStack network is a configuration file, or what heat would call an environment file. And it has a set of properties for my OpenStack cloud. And then I have a separate one for Amazon that has all of my parameters. Notice they refer to Amazon sizes and Amazon image IDs. And then also this resource registry. And this is the capability that's already in the publicly supported OpenStack heat engine that we're able to leverage in order to deliver this value. So if I come back in here, I'm going to modify this for the demo. We'll make this 20. If I go back into my Horizon dashboard, I'll show you there's nothing up my sleeve. So under networks, I have one for the .18, but there's not a network for 20. And if I go back into my Amazon account, again, I have a few networks here, but none that are 172.20. And now we'll go and provision this. I'll call this portable network. Let's do OpenStack first. I'll pick the configuration file. And notice that when I do, all of the parameter values are filled in whatever the default values are. I can still override them. But this will give you a little bit of feedback. And notice that the image ID is not resolved. It's because it was for a different cloud. I would get that validation feedback if I click to go. But let's not do with that one right now. And here again, the flavor is small. When I do Amazon, it'll be T1 tiny. All right, we'll click Provision. We have one validation error. I need the network ID. So let me actually. So the network ID is set up as a parameter. This is the public network that we're going to attach to when we provision the template. So I'll pick my configuration for OpenStack and specify my image ID, and then the network ID, which I forgot here. I'm going to go. EXTNet is one that we have that's already routable into the network. All right, so provisioning has begun. Let's also kick it off for Amazon. And in this particular build, once I provision it, it will succeed, but you'll see a small red dialogue pop up with a sort of a false positive error. We had the same idea of kind of connecting to an existing network in Amazon. All of the flavor information, notice that by changing that configuration file, I now get feedback for the Amazon cloud instead of the OpenStack cloud. So all the flavors that are available to me are here. If I wanted to pick a different image, we actually whitelist the images as part of our configuration. But I could easily change those out as well. And then I think that's all I want to change. Yep, and I'll click Provision. And so now that's going to start. Here's that false positive I told you a minute ago. And then we'll see these come online. So here's the OpenStack 20 environment. It's already well on its way to completion, if it's not already done. Here I can see my network. I can drill into Horizon. I'll do a refresh here. We'll see the new 172.20 network come online. If I go and look at my instance, I'll see it's been assigned a IP address from that new network that was provisioned. Over in Amazon, let's refresh my view here. Again, I have my 172.20 network that's been created. I look in my subnets. I can also see that it's available here. And then routing tables are interesting because it's a concept that's not directly in OpenStack. So this, again, is just an example of mapping different concepts. So fortunately, I think I've hit the content that I wanted to show live. And I'm getting the wrap up signal here. The only other items that were here were just a few comments about history, which we can skip. They'll be available. I'll post these on SlideShare as well. So if you look for Michael Elder, you'll find them. If you're curious about that. But other than that, we welcome feedback. Either Twitter or email. Feel free to reach out. And with that, we'll take questions. Thank you.