 Good morning, everyone. Wonderful to see so many people here. Really exciting to see so many people interested in heat. Can everyone hear me out there? No? OK. So what we're going to talk about today is an introduction to orchestration. And actually, it'd be good to just to get a show of hands, first of all. How many people here are already using heat? Can we just get a? OK, that's cool. And the rest of you I hope are kind of thinking about using heat. Can we have a? OK, great. Well, it's really exciting to see you all here. What I'm going to talk about this morning is a bit about what heat is and why you would want to use it. And once I'm done with that, Steve is going to take over and give you a little demo. So he's going to start with some basic templates, show you how they fit together, turn it into a full demo. So it'll be interesting to see if that works. Always the plague of trying to do a live demo in front of a bigger room as it always fails. So it should be entertainment value for you this morning. And if we have a bit of time after that, I'm going to talk about kind of what we've been doing recently in the outstream community and heat in the Ice House release. And the things that we're talking about going forward into the junior release, which obviously the design summit hasn't happened yet, so we're still thinking about those. But we can give you a bit of a preview of what we're thinking about. There's still some more seats up the front here. If you run tripling in now, it needs to grab a spot. And we will try to make time for questions afterwards. And just a reminder, this is being recorded. So if you have questions, please come up to the microphones in the aisles here so that we can get you on the video. So what is orchestration? The analogy I like to use on this is orchestration is like software configuration management, but for your infrastructure. So if we think back to the early days of configuration management or before the early days of configuration management, you would have your custom built server that you'd tweaked all your little things on. And you hoped that it never died because you probably didn't know how to ever recreate it. I'm sure we've all done this. I know I have. And then as time went on, that became something that was not going to work anymore because your servers did die. And you had to recreate them, usually at the worst possible moment. And so maybe you thought, oh, I'll write a script that will create my server and set everything up. And then I won't have to worry about how to set it up again. And that worked fine the first time. And then you wanted to change something on your server. And you thought, OK, I'll just go in and tweak this thing. Bad idea. And maybe you remember to update the script but probably you didn't, maybe. And so configuration management came along and said, OK, forget about this imperative thing. Do this, do this, do this. Let's just describe what do we want? What is the end outcome that is the good result here? Let's capture that. Give it to a tool that decides how to create it. And then when we want to change it, we don't change the real thing. We change the description and let the tool figure it out. And this is not new to any of you, I know. But the reason I'm telling you this story is that I want to convince you that we have exactly the same problem now with infrastructure. So we're going to infrastructure as a service cloud. Software now controls all of the things in our cloud. You no longer have to go out and ask your IT department, hey, can you provision me a server? Hey, can you hook it up to this network? Hey, can you do this? You have complete control over all of that in software. And so now we have this enormous power in our hands, but we have the same problem about trying to control it. And this is the problem that he's just trying to solve. So instead of writing your scripts to set up all your nova servers and connect them to their networks and their volumes and all this kind of thing, we're just going to say, OK, let's create a heat template. It describes what our infrastructure wants to look like at the end, and we're going to give it to heat, and heat is going to set it all up for us. And then we want to change something. We change the template. Heat will set up, will perform the changes instead of having to fiddle around manually with it. And by the way, at the end, when you're done with that application, heat will delete everything for you and you'll know that everything is being cleaned up. You're not having resources sitting around costing you money after you've long done with that application. So that's kind of the value that orchestration is trying to provide. And I hope everyone who put their hands up earlier saying that we're thinking about deploying heat is now convinced that they need to do it immediately. Am I right? OK. So I wanted to talk a bit more about configuration management because a lot of people get confused. They see the example templates that we have. And it's a great demo because we have a lot of example templates that set up WordPress. And you can see it in a very tangible way. You fire up WordPress, you log into the console. When five minutes before you had nothing, now you have a VM running a database of WordPress and they're all connected up and it's working. And you can access it through your web console. And that's a great demo. But it's not necessarily representative of how you would deploy applications in the real world. So you have heat to do the infrastructure side of the orchestration. But you still need an answer to that problem that software configuration management was solving in the first place. So basically, across the spectrum that I have here on the side, you need an answer for all of that to manage that over time and make sure that you can handle changes to that over time and that you have everything under control. And so software configuration management tools work great with heat. They're complementary categories of product. So I put Papa down here, but it could be shared for anything like that. Or you can roll your own. You can do whatever you like. Heat is trying to be very agnostic about what you do on that side, on the software side, because heat is part of OpenStack. And OpenStack should not be dictating what you can do on your server. We want to present a good interface, a good API, that you can do whatever you want and interact with OpenStack. And so one of the things that we've actually implemented in the I2S cycle is this kind of, you'll notice there's a bit of overlap here. And I'm calling this part software orchestration. I don't know if that's the correct technical name. But basically, it's the integration point where all this information from your infrastructure in terms of what servers you have, their IP addresses and that kind of thing kind of need to be fed into your software applications. And Steve Baker has done a lot of great work in I2S to get us into the software orchestration space. And we think that's as far across as heat is going to go on that spectrum. So it may well be that you have completely stateless applications. And so you never need to make changes to your software configuration. You can just create a new server with the new configuration you want and kill the old one. That may be your answer to that question, but you need an answer to the question. And you'll notice that that kind of heat is approaching this from the right-hand side of this graph here. So we're moving from the right kind of towards the left. It's very difficult to move from the left towards the right as things like Puppet and Juju on there have discovered. You can't go too deep into the orchestration without kind of becoming a part of OpenStack almost. You lose the flexibility to say, OK, we're going to work with anything because orchestration is very tied to the kind of cloud that you're using. And so it's difficult. Puppet and Juju, they'll spin up a server for you, but they can't configure all this other stuff that heat can because heat is part of OpenStack. So just to know a view of how it fits in, the heat layer sits on top of the other OpenStack services in much the same way that the dashboard does. I like how we have two names for a project in OpenStack as if it wasn't confusing enough for the new people. So we had the orchestration layer and basically it talks to the APIs of all of the other OpenStack services in much the same way the dashboard would. And the dashboard, in fact, you can use heat through the Horizon dashboard and Steve will demonstrate some of that in a moment for you. So that's kind of where we sit in in the OpenStack stack. And so the fundamental kind of unit of currency in heat is a stack, which is a heat template is what generates a stack. So you write one template with a bunch of what we call resources in it. And each resource is something, it's a noun, it's something in the OpenStack API that is a thing, an object that has a UUID usually. And heat will create that object and keeps a track of it, keeps a track of its ID. And resources, you can have a bunch of resources in a stack. One of the things that the OpenStack API support is creating heat stacks, right? So you can have what we call a nested stack, which is where a resource in a heat stack points to another heat stack. And so you can end up with like a tree of stacks where you can break down your application into kind of component parts and compose it up into a tree of nested stacks. So it's very flexible and very powerful in terms of the ways that you can arrange your code and you can arrange for reuse of parts of your infrastructure and that kind of thing. And the resources kind of have relationships between them which are mostly automatically inferred from the template. So I've got a little example there where you have like a volume and a server and a volume attachment which the parameters to the volume attachment are the IDs of the volume and the server. So heat can infer from that template, okay, we're getting the ID from the volume, we're getting the ID from the server. We need to create those first and then we can attach them. And so for the most part, this is all kind of inferred automatically from the template. You can also include explicit dependencies in the template. I think it's probably time for you to take over and Steve's gonna talk a bit about how to put the templates together. Yep. Thanks, Zane. Yeah, so just to introduce myself, my name's Steve Hardy. I've been working on the heat project for the last couple of years and I was just gonna follow on with a little bit more of a real world example related to what Zane's just been discussing about volumes and volumes attachments. I'm gonna start with an overview of what a heat template looks like. So on where some of you may have familiarity, but I'm gonna talk about a few features that you may not be aware of. But I'm gonna start with the basics which is basically just to explain what goes into every heat template. One of the benefits of defining your infrastructure using a heat template is you've got this common interface. Every template has optional parameters which are basically inputs, which allow you to parameterize a configuration inside your heat template. You have a block of resources, which is things like your server and your volume and volume attachment, network resources, object storage. All these kinds of things which you can gain access to directly in the underlying OpenStack APIs can all be described through resources defined in the resource section of the template. And then finally you have an optional output section where if you need to say get an IP address of a server after you've created it, that can be provided by the output section of the template. And then each resource has a kind of a similar looking interface. You have properties which are the input to the resource and then you have attributes which are effectively the output of the resource. So as I mentioned, nested stacks a minute ago, it's worth remembering that the kind of parameters are very similar to properties and attributes are very similar to outputs because we leverage that symmetry in the way which we expose some of the nested stack interfaces, which I'll talk about in a few minutes. So here's just a really simple example just to give you a demo of what the heat orchestration template syntax looks like. So we kind of started off primarily supporting the CloudFormation template language and it became fairly rapidly apparent that people were keen to have a native interface specific to OpenStack. And so over the last couple of development cycles, we've been working very hard to stabilize the heat orchestration template, the hot syntax. And so this is a nice, simple, clean YAML syntax. If you're familiar with other orchestration services, it'll probably look quite familiar. But you can see here, you basically have parameters which are defined in a block where you can have a name for the parameter. You can optionally have a default value for it. You can specify constraints so that you can reject values which you know are not going to work. You then have a resources section where you specify the type of resource. And heat has got a pretty wide variety of resource types now. We're constantly playing catch up because all of the other projects are adding functionality very, very rapidly. But that's a nice problem to have. Each cycle, we're adding new resource types and getting lots of good contributions back from other projects. Such that pretty rapidly after functionality is added to other OpenStack projects, you should find that it's going to be accessible via heat. And then finally, I mentioned the output section here. You will have an output section where you have a name of a particular output. And then you reference the tributes of the resource typically, such that you can then expose that after creating the stack. So talking about parameters a little bit more, if you're used to creating heat templates already, there might be a couple of new things here which you've not had exposure to. You can specify constraints in the hot syntax which allow you to have either a list of allow values, for example, which is the first example on the slide, or you can specify things like a range of valid number values, or you can have a pattern for a regular expression that is evaluated. And new for ice house, there's a custom constraints feature which basically allows you to say, this particular string needs to match an imaging glance or it needs to match a key pair in Nova. So that allows much more dynamic evaluation of parameters which are passed to your heat stacks. So before I go into the examples, here are some links which just provide you a starting point if you want to investigate the template language and resource interfaces further. We've got quite a good template guide which is automatically generated from the code as we write it. So that's actually in the docs.opens.org developer area. That's very applicable to non-developers as well. Anyone who's developing heat templates is likely to want to look at that guide. There's also a regularly updated hot spec which basically describes the structural aspects of the hot language and the template syntax. We've also got a template repository where we try and add examples which you can use. That's the OpenStack heat templates repo. You can pull that and find a number of examples which may help you when you're trying to figure out how to write your own template. And then in terms of heat itself, that also provides a nice couple of commands when you're using the heat client CLI. You can do resource type list which basically gives you a list of all of the resources that heat the service you're talking to knows about. This can be quite useful if you're looking at the trunk documentation. We only at the moment have the template guide automatically generated from trunk. If you're perhaps using an older version of heat, resource type list is going to help you out because it's going to tell you the resource is available on the service. And then we also expose the schema for each resource. So if you need to know what sort of attributes or properties are valid for a particular resource, you can use resource type show and then the name of the resource. This is all basically the same information that's included in the template guide but you can gain access to it directly via the heat service if you like. And also I'm going to talk about some template examples in a couple of minutes. I'm going to push them after the presentation is finished to my GitHub area in a demo templates repo. And I'll also put a link up to where these slides will be so you can pull them later on if you wish to refer to them. So this is just another summary of the nested stack hierarchy which Zane mentioned earlier on. This is quite a powerful abstraction so I thought it was worth highlighting it for you all. And that is that he isn't just a flat declarative model. You can declare a unit of functionality. For example, a server which has some storage and has a particular application on it. And then you can reuse that in a nice modular way. So you can refer to it in another template and create one instance of it. We have some group resources which allow you to create either a resource group or an auto-scaling group. This basically allows you to say I want 10 of this particular heat stack. And so it gives you quite a powerful and flexible way of reusing templates once you've written them. And it also allows you to have much better separation, perhaps if you've got different teams within an organization who are maintaining different aspects of your infrastructure or particular teams which maintain versioned middleware, for example. You could expose all of that via independently maintained heat templates. So this is just a quick example of how you can create a nested stack. Using hot is very, very simple. One option is just to put the name of the template that you want to refer to in the top-level template. So here you would have mynested.yaml, which is the stack which you've created. And obviously this isn't doing anything, but that might contain a load of additional configuration for a particular application. And then top-level template, you can just put type and then the name of the nested template. They mentioned Horizon. The heat support in Horizon is rapidly improving, but at the moment, if you want to deal with nested stacks, you probably want to use the heat client CLI because there are a few limitations in terms of resolving the references to the nested template in Horizon at this point in time. That's something we're hoping to address during Juno. So the next step on from nested stacks, you notice that in my previous example, there's a hard-coded reference to the nested template. So that's one of the bad points of the CloudFormation interface to nested stacks is the fact that you end up with a hard-coded URL in your template. And if you just want a quick way of creating a nested stack, the interface I mentioned to you just now is a perfectly valid way of doing it. But an alternative is you can create a resource type alias, which basically means you can say, this type name refers to this template. And the nice thing about that is that it's not restricted to names which don't conflict with the built-in type. So perhaps you want to define OS nova server resource, which overrides the built-in implementation with some superset of functionality. And that's absolutely possible for any user of heat. You don't need to be an administrator of the service itself. So this is just a little bit more information on that. There are top-level environment files and you basically have a resource registry as a section in there. I'll skip through these quite quickly because I'm aware we're probably gonna be a bit pushed for time. And so this is an example of an environment file. You can have my custom server and that refers to a heat template and that's basically just an alias for an nested stack. The other thing which environments allow you to do is specify parameters. So this is an alternative to passing parameters into your stack every time. And the nice thing about this interface is it gives you a very easy way to implement, for instance, the staging workflow. Perhaps you have a set of parameters which change between environments or alternatively the parameters don't change but the version of the templates changes based on the version of the application in your nested stacks. And this allows you to control all of the things which are likely to change in one file whilst leaving the declarative model in the stack templates unchanged. So here's just a quick example of how that looks in practice. So you have the nested stack template at the top. You have the top-level stack in the middle, mystack.yaml, and that refers to a mycustomserver resource. And then you just pass in an environment file which says mycustomserver refers to mynested.yaml. And again, at the moment, if you want to use this interface, you need to use the CLI Python Heat Client interface because that can resolve the nested stacks for you. We're hoping to add that capability to a rise in the near future. So I'm not gonna talk about software config in any detail but if you're interested in the software config functionality which they mentioned earlier on, Steve Baker, who wrote most of that stuff, has got to talk tomorrow. The details are up there. You may want to go along and check that out if you're interested in allowing software configuration via Heat and integration with existing config management tools like Puppet. So now's probably a good time for me to quickly attempt this demo. I'm just gonna do a very, very quick example of how you can launch HeatStack via Horizon providing my laptop works. So I'm sorry about the resolution on this. It's a little bit difficult for you to see but when you log into the dashboard, you'll find that there's the project area and there's an orchestration option on there in recent versions of OpenStack. If you click on stacks, there's a launch button just here. So you can click on there and then you have a few options here. You can either have a URL, perhaps you've got a local Git repository or you want to refer to a template example on the internet or a local file or you can directly enter the template here. I'm just gonna use the local file in this case. So I've got this example. I'm gonna push this example to GitHub after we finish this. And I'm just gonna select the YAML file here. You give the stack a name. So this field here, the password for user, we should be able to remove this soon. This is basically an implementation detail of previous versions before IceHouse where heat needed to store a password in order to do deferred operations for things like auto scaling. We fixed that in IceHouse and so hopefully quite soon we're going to be able to remove that box or at least make it optional in Horizon. So then you just go down and click launch at the bottom here. You'll see then you've got a stack that is being created and there's this topology diagram which is quite a nice way of looking at the resources in your stack. There's only three in this case. There's a volume, a volume attachment and an over server. So heat then goes away and as Zane said it will create the nova server and the volume and then once that's done it will create the volume attachment which attaches the nova server and the volume. And in this particular example, I've got a very small amount of user data where basically I attach the, I make a file system and then create a test file. So then if you go into the compute area of the dashboard you'll find that there's a summit demo instance which has just been created by heat. And now you'll see that we can log in via the VNC console. So you can see here we've got the VDB device. It's mounted it as in the user data I just showed you. On slash MNT and then it's created the test file. So that's just a really, really simple example. I was gonna do some more detailed examples showing provider resources and nested stacks. I don't think we're gonna have time for that but I'll put them into the repo so you can refer to them afterwards. That's hopefully just a brief summary of how you can get started using heat. As I mentioned, what you might find is if you start wanting to investigate nested stacks you can use the Python heat client CLI tool which provides a very simple interface on the command line. So I'll pass you back to Zane now who's just gonna cover some roadmap summary. Yep, sure. I didn't see you pass any parameters in a heat through Horizon, is that supported as a? It is, yeah, that's a very good point. So let me just quickly go back to the dashboard. So the reason I didn't have to pass any parameters is because I gave defaults to all of them in the template. So here you can see I've given a default stack key and then I've got a default of the Cirrus image which is the image that I've just booted which is in glance and then I've given a default volume size, one gigabyte and I've given a default instance type. So you can pass the parameters and I mentioned the constraints here. The nice thing about specifying a list of constraints is that Horizon can go and pull those constraints into the UI and it gives you a dropdown and so you can choose from one of the allowed values. So here's an example. There's the dropdown there which has got the two image types which were in the allowed values in the template. So that was the reason I didn't have to pass any values explicitly. Yeah, so all of the values in the allowed values get put into the Horizon interface and you can specify defaults for each one. If you need to have explicit input for every one you would need to enter them manually into the UI which you can do via Horizon. The reason I didn't make any of the non defaulted values just to make it easier for me to demo. As I mentioned earlier on, if you think you're gonna have a long list of parameters which you can't default reasonably, the way to do it is to use an environment file which you would need to use the CLI interface for. And so you just do heat stack create, stack name, minus F, the name of the template and then minus E, the name of the environment file and say I was gonna demo that but I'm probably not gonna have time. If you have a look in the demo templates repo that I'm gonna push to get help later then you'll be able to see how that works. Cool, so I'll pass you back to Zane to wrap up and talk about the roadmap items. Cool, thanks Steve. So I think we have like seven, eight minutes left. So I'm just gonna go through this really quickly because I wanna have time for questions. If anyone's got questions maybe start queuing up by the microphone. So thanks Steve for putting this slide together for me because I thought back at the ice house and I thought, what have we done in ice house? Things just move so quickly that stuff is happening all the time and I can't keep track of which version it's in but. So a big one is the hot DSL. So the new heat native heat orchestration templates that is kind of officially supported now. It's stable. If we make breaking changes we will bump the versions on that. So you can write templates in that language with confidence and that's the one we would recommend from this point onwards. So that's a big one. Software Confeg, Steve Bagger's done great work on Software Confeg. Go to his talk to learn more about it but that is kind of the first cut of that is in ice house and there will be more improvements to come. Stack domain users. So Steve alluded to this earlier that you had to have the user's password to kind of, no, this was a different thing. You had to be admin in order to create a Keystone user in order for your service to talk back to heat to let us know that things are happening which obviously doesn't work for when you're not an admin which is most people. So that is fixed now. You don't need to be admin. We will create users in a separate domain. Native Auto Scaling Resources. So this is kind of on the road to getting a separate Auto Scaling API. We're now Auto Scaling Resources where you can Auto Scale basically provide a resources so you'll be able to Auto Scale a stack or any kind of resource instead of just a server. So that's a big improvement and there will be further improvements on that. Hopefully culminating in a separate Auto Scaling API so that you won't have to go through heat to use Auto Scaling. Plugable Parameter Constraints. Steve mentioned that Plugable Template parsers. So the template parser is now, we have plugin parsers basically. So the CloudFormation parser and the hot parser are separate plugins. You can potentially write your own custom ones and we're going to use that for, when we do make breaking changes for bumping revisions of so we can have multiple versions of hot parsers. Scale with Heat Engine. So you can now run more than one heat engine at a time and jobs will be kind of farmed out between them. And Management API additions. So yeah, we're kind of a constant process of improvement going on for operators with the Management API. And can we have a look at the house, thank you. So this is all very provisional because the design summit hasn't happened yet and we haven't committed to doing anything in particular for Juno, but some of the ideas we've had, a lot of people have asked us about when we're scaling down an Auto Scaling group, how can we pick which service to kill? So that's something we're thinking about a lot. How can we do a cleanup step before we kill the service to make sure we've evacuated any workloads off that? That's something we're thinking about. Update. So at the moment if you fail during update, you have either the option to roll back or not. And so if you either don't roll back or if it fails during the rollback, then there's pretty much that's the end of your stack. You can delete it and that's the end of your options. So we're planning to fix that. That's hopefully happening in Juno. I'm working on that, not as we speak, but next week I'll be working on that again. Rolling updates. I think we have rolling updates now. Roller core scaling groups is just a bit binary updates for a stuck update. Oh, okay, right. Stack check, stack preview. So we're looking at kind of convergence over time so you set up your stack and we know that it's good at the time we created it, but how do you check that it's still in spec later on? That's gonna be a key area of focus. And the next couple of releases probably. And also, how do you cancel an update while it's happening that's kind of tied up and how do you recover from a failed update as well? So interesting stuff happening. Design Summit sessions are on Wednesday. If you have feedback for that, then please do come along. Steve's talk is tomorrow on software config. Highly recommend that one. If anyone has questions, please come up to the microphones and... Yeah, so I mentioned earlier on, I was gonna push these slides, which includes the link to the example templates, that bottom link there, github.com, hardys presentations, there's already some decks in there, but these will go on there later today. Yeah, hi. I've been looking at the open, or them, sorry, the Murano project, which basically is a workflow engine that runs on top of heat. And I've been a little confused about, is that gonna get integrated? Is that gonna become part of the heat project? Can you explain what the relationship's gonna be? So I don't think it's gonna become part of the heat project. It's a tool that uses heat. I think they're still kind of an early stage in figuring out where that fits in, but it certainly fits in on top of heat. But it will be a separate project. And I mean, what they're aiming at is ways to combine different parts of applications, potentially from different sources, and kind of bring them together and have a catalog that the operator can provide so you can pick from applications in the catalog and say, you know, I want this application with this database and this web server or whatever and grab them and put them together. And they will use heat under the covers to do that. The exact details are still yet to be worked out, I think, but there will be design sessions about that on tomorrow morning, I think. So you might want to come on to that. Okay. Yes. Yeah, as you iterate hot, will you continue to invest in cloud formation, translation and extend out functionality? And then two, second question is, can you comment about any, within Red Hat, a co-operation between the new OpenManageIQ project and heat, is there going to be any tie-ins there we can expect? So to the first question, cloud formation will continue to be supported. We're not planning to make that go away. There is, I know cloud formation are also, you know, changing their template format over time and adding improvements. Hopefully we will be able to implement those changes that will be a bit hind, obviously, but we would like to keep up with them. But it's not the focus of kind of innovation anymore. It's like, that's to help people move from AWS to OpenStack. We want to help them move to OpenStack. But, you know, we're not innovating in the cloud formation area. I don't have what to say about kind of tie-ins with ManageIQ. There's no plans at the moment that I'm aware of. Yes. What a question about what happens when things go wrong, particularly if you're talking about large, large configurations. Are there different policies that you can apply to say, well, as long as you give me at least four servers, I don't care, or you don't tell them down if one's gone wrong, or something like that? Not at this stage. So that's kind of something we're looking at in the future in terms of recovery from failures. Certainly, so the triple O project is deploying OpenStack on OpenStack with heat. And so they obviously run into this problem a lot. They're very interested in solving it. And so we will be working closely with them. Kind of one of their core guys is Core on Heat as well. And we'll be working with them to try and solve that. But yes, it is, that's an area that needs work. Can you go stand by the mic, sorry? So we want the people on the video to be able to hear the questions later. Thanks. I would like to know, when are you going to start supporting Tosca in heat? Because our understanding so far is that OpenStack heat only handles the infrastructure. And we need the application in some kind of interaction with OpenStack heat. Yeah, so that's kind of an open question we've been working for about a year with some of the Tosca folks. One of the things, there's a project starting up that's kind of like a translation layer between Tosca and heat. So there'll be some kind of service where you can feed it a Tosca template and it will parse it out into heat templates. So Sadev Zala from IBM is working on that. It's a Stackforge project, so that's happening now. There is a possibility, I mentioned before, we have now a pluggable template, Formats and Heat. So there's a possibility that we could have a Tosca plugin that there's kind of no technical obstacle to that. I don't know if anyone's kind of queuing up to implement that, but it's a possibility. The Tosca is a much more kind of abstract thing than heat. Heat is very concrete. It's like these OpenStack resources are what we want you to create. Whereas Tosca is like, these are kind of the constraints on which the resources we want you to solve for. So it may end up there's been kind of a solver level that says, and this could be the translator project that says, okay, here's these constraints. Let's solve them into something concrete and spit out a hot template that is a concrete kind of representation. That's one way it could go. There are other ways we can discuss it more afterwards if you like. Yes. I think we're out of time. I noticed that Heat introduced a user called EC2-user when it comes up. Is it coming from Heat or the Cloud in it? So that's actually been removed in the latest version of Heat. Originally, we were passing some user data to Cloud in it which set that user. It was just a historical thing. For my house, that's actually been removed so it should use the default user created by Cloud in it for whatever platform you're launching. Okay. I think we're out of time now. I think we're out of time. Thanks for listening. Yes, thank you very much everyone and we will be.