 Perfect. Hello everyone, good afternoon and welcome. My name is Navin Joy. I'm a cloud architect with Cisco. And my session is about an introduction to cloud service definition. Since this is an introductory session, I will not assume that you know any background material. So we'll start off from the basics. And at the end of the session, I will also show a demo. So I have OpenStack Kilo release running on my system here. And we will deploy some of the artifacts and to illustrate the concepts. You will see the template being orchestrated and the stacks being created. So on the agenda today, we will talk about declarative modeling, what that is. We will look at the service definition language briefly. And I will walk you through a real world scenario, pretty realistic. Some of these scenarios that I worked with my customers to deploy services. We will look briefly at the template structure. And we will start from a conceptual service model, which is a diagrammatic representation of the service that we will be deploying. And from there, we will translate into a template-specific representation that is suitable for deployment. Then we will look at some minor details for service definition that will help us understand how these various resources are connected and how that template is being composed, very high-level requirements. And finally, we will do the live demo if everything works. Basically, go ahead and create the stack and see the output. So let us look at what a declarative approach is. So in the declarative approach, you primarily describe what should be accomplished and not exactly the details of how to get there. Essentially, you think like a manager, like who is creating a high-level plan without the details. And then you let somebody else, like an employee who is working for you or some specialist, figure out the details. So in this case, the manager is going to be you and the person working for you is the heat service. So what you are going to essentially do is to create a description of your infrastructure or your application architecture in a language that your service can understand. And then what you're going to do is to send that description over by an API call to the service. And the service is going to parse all the details and it's going to do the various analysis inside and figure out what resources you want to create. And then it's going to go ahead and make all the necessary calls to the OpenStack services such as NOVA, Neutron, Cinder, and so on and so forth. And then finally, it's going to deploy that service for you and then it's going to report back on the state of that service. So that is the, in essence, the declarative modeling. So all you need to know is the high-level description of what you want to accomplish and the service is going to figure all of that out. So now this is key is how do you describe services? So there is a language called YAML. It is designed to be a human-friendly readable language. YAML stands for YAML in markup language. So it's not ugly like XML. You can read it easily. And in order, since I'm not assuming any prerequisites, I will give you just enough knowledge to be able to read a specification. So all you need to know is these three bullet items. So if you want to list items, you can either use the familiar square brackets or you can use a dash and a space. So if you want to do key-value mappings, you can use a colon and a space representation or the curly braces key colon value. And you always use indentation to define scope, basically to tell when a list item ends and the other list begins. So you will see that. Let's look at the scenario. This is a scenario that, you know, a piece of it is something that I've worked with my customer. So a company has deployed OpenStack with orchestration service and they want to simplify application deployment. That's the goal. And they have two key requirements. The first requirement is to create a repeatable configuration for the infrastructure. It's important to know that this is just a configuration. When you create this repeatable configuration, the actual resources are not created at this point. The second is the instantiation of the configuration. So if you are familiar with object-oriented technologies, you create a class. At that point, your object is not created specification. And then when you instantiate it is when the actual object is created. So similarly, you create the configuration and the instantiation of that can be done in a predictable manner. And who does this instantiation? That's the service. So let us go from the requirements to concepts. The first requirement was to create a repeatable infrastructure configuration. So that translates into the YAML template, which also functions as a specification. The second requirement is that you have to be able to create unique instantiation of the configuration, which translates into a stack. And stack is a set of resources that you create and you manage as one unit. So all other operations, all operations that you perform after you create the stack are stack operations. So if you want to add a new resource, so if you want to modify resources, you modify the template and send the modified template to the service. And the service is going to figure out what changed and it's going to make the necessary adjustments. So the instantiation is called essentially the stack. Now here is a description of the high-level service that we will be deploying. So the service has two components, component one and component two. Each of this will be modeled separately. You can create repeatable instantiations of both of these components separately. The first component is called a virtual private cloud, which is an isolated section of the network. And as shown in the right-hand side, you have an internet gateway that is represented by a router connected to an external network. And the router has two interfaces to two inside networks. And the component two is an instance with a volume attached to it. It's very straightforward. And we have also defined runtime parameters. And these runtime parameters are used to customize the stack deployment. So every time you create a unique instantiation of this particular service, which is a component one or two, you can provide different values for these parameters to create a slightly different flavor, if you will, for that service. So for the first service, we have created network name and subnet blocks at the parameter, in which case as you instantiate it at runtime, you can provide these values. Similarly, for the second component, we have specified SSH key, image, flavor, volume size, and the network to which you want this app to be deployed. So this is a high-level model of the service that you want to create and deploy to OpenStack. Now let us briefly look at the template structure. The template has five sections. The first section, of course, is an input section in which you specify the parameters. And there are two sections that are pretty self-descriptory. One is the heat template version. And heat uses that to determine which version of the template you're using. The second is a description. You can provide anything that describes your stack. And in the resources section is where you describe all the resources. Remember the declarative modeling where you primarily describe all the resources without the details and let the service figure all those details for you. So this is the key section that is required, resources in which you pretty much describe what you want. And the output section is basically the values to be returned after the stack has been created. For instance, you may want the IP address that has been dynamically assigned and then you want to get that value after the stack has been created and pass it on to a different application or things like that. So you can ask the stack to return certain outputs. So this is a conceptual model for a VPC service that we described earlier. So in this model, you can see all of those three sections. Parameters have been identified, resources and outputs. And the arrows show the dependencies. So here you can see that each resource is assigned a unique name, otherwise known as an ID. So we have seven resources. What essentially we have done is the network topology that you have seen in the previous slide has been taken and broken down into resources with each resource assigned a unique name. So you can see we have networks and subnet. And there is a relationship between the subnet to the network. So you can see subnet 1 is dependent on the network, which means that the network has to be created first before you can associate a subnet with it. And heat is going to look at all of this. It's going to resolve these dependencies and execute the creation of these resources in the correct order. Similarly, if you look at the parameters section, you have four parameters and these parameters are used to customize the stack. Every time you create a deployment of the service, you can adjust the values for the parameters to create something unique. For instance, you can create a first time when you create an instantiation of the service, you can assign different names for network 1 and 2 and different subnet cider blocks. So that will create the service in a unique manner. And similarly, we have modeled the MyApp service, which shows the instance volume and the attachment and the dependencies between those resources. So you can see the volume attachment requires the volume and the instance to be created before you can attach it. So heat is going to do that dependency mapping for us and then execute make calls to NOVA and Cinder to be able to create all of these resources before it actually performs attachment. Much like how a human being would do, heat will take care of doing each of those operations independently and keep all of that resources created together in a stack. And the left-hand side shows the parameters. So we have identified, so each time you deploy this template, you want to be able to provide a unique key, image, flavor, the network to which you want the app to be connected to and the size of the volume. And finally, from the output standpoint, you want to get the instance IP as an output because that's going to be assigned dynamically by DHCP, at least in this scenario. So once you create this conceptual model, the rest is going to be easier because you can take this and translate it into a specification and then send that specification to the service, which will deploy all these resources. So just in order to define the dependencies, you will need to know just these three items to be used. One is the getResource function that you can use in the template. What it does is it references another resource. So use getResource and a resource name, which says that resource A, when it uses this function, it references some other resource, so that dependency mapping is there. And getParam is the function that is used to reference an input parameter. And getAttribute references a resource attribute. So why do you really need these functions? Because values for these are determined at runtime. So that's why you tell the heat engine to say, for instance, when you create a subnet, if you want to associate that subnet with a network, you will have to provide a mapping from the subnet to that network. And since that network doesn't exist yet, you want to be able to tell it, use this getResource function to get the value of the network that you have created at runtime and use that to map the subnet. So since this is all runtime operations, you tell heat to execute the correct order or the correct dependency or use the right input and get the right output using these functions. So this is just a brief overview of how these functions are used. And you can see that in this resources section, we have defined three resources, network one, two, and a subnet. And in the properties section, under the name property of the network one, you can see that a getParam function has been used to reference a parameter named network one. What this tells heat is that when you deploy network one, the name of the network should be obtained by looking up the value of the parameter named network one. Similarly, on subnet, you can see that the network ID references a resource named network one. What that tells heat is that when you create the subnet, the network ID has to be referenced, has to be obtained from the resource named network one that it has created. So all of these, so this is just a snapshot. So all of these YAML files are available for you to download. I've posted it and you can download, play with it and create your own stacks and examine it. So feel free to extend it and use it. So now we will go to the demo in which in the first step, we will create a virtual private cloud by deploying the vpc.yaml template. And in the second step, we will show the repeatability by creating another virtual private cloud by deploying vpc.yaml again the same template with different parameter values to create a unique flavor for the virtual private cloud. Then step three is we will deploy the app to the virtual private cloud and then attach that app to one of the networks. So I'll switch back to my demo environment. So I've logged into the open stack release which is a kilo release that is running here locally as a VM. And now I'm going to the orchestration service. When you click on the stack, you'll be presented an option to launch a stack. So you click on launch a stack and it will prompt you for the template source. What this means is that it is asking you for that specification that you have composed. So you choose a template file and since we want to deploy the virtual private cloud, so you choose vpc.yaml. vpc.yaml essentially contains all of the dependency mapping. It has that router with attached to the external network with two interfaces connected to two internal networks. So that is the topology that we have defined. Then the environment source is you can either provide the values for the parameter either using a file or you can type it in manually as in the next window. But in order to better present it centrally, let's use the file-based approach. So I have put all the parameters and mapped it to a value in the vpc.yaml. So now when you click next here, what happens is that it's asked for a stack name. Let's name it vpc1, provide the admin password and you can see here that the parameters earlier on that have been defined in the template are right here with these values, rednet. So we are deploying two networks named red and blue and two cider blocks. All of these values are provided at runtime in my environment file. It has been picked up from that file. And another cool feature here is that you have the ability to roll back the stack on failure. Let's say when you are deploying this whole stack, heat finds out that the virtual machine cannot be deployed. There is some error because let's say you ran out of memory and at that point instead of just keeping that stack in an inconsistent error state, if you check rollback, heat will automatically detect that now I cannot create, I cannot realize the specification. So let me go ahead and roll it back. It will go back to the clean state. So that's a cool feature. So now just to go back to the virtual private cloud, it has two networks named red and blue and two cider blocks. All of these are runtime values that you have specified here. So now when you hit launch, at this point what happens is that this specification has been sent by an API to the heat service and heat service is figuring out that it has to create those resources and it has gone ahead and created it. So now it says create complete. It's a good thing. So let's go to the network topology and look at the service. As you can see, a virtual private cloud has been created with a gateway router attached to two networks named red and blue and the correct subnets that we have provided have been used by heat. So in order to illustrate the repeatability and how easy is to create this model, let's go ahead and deploy the same template again but provide different values for input parameters such as different cider blocks, different network name and see that an identical model that is highly predictable, exactly the same model has been created. Go back to stacks. So you have one stack. So I'll launch the second stack and so I have not changed the architecture. The architecture is in the same VPC YAML. So I'm deploying the same YAML file but with a different environment. Let's call the stack VPC 2. So here you can see that the input parameters are red net 1, blue net 1 and a different cider block. So now when you launch it, heat now goes ahead and creates a stack and it's in progress right now. So it has created it. So let us look at the stack it has created. So now we can see that an identical representation of the virtual private cloud has been created again in a very predictable manner. You can see another router attached to two networks, red net 1 and blue as you have specified. All you have done now is to once you have defined your application or once you have defined your network architecture, it's easy to create repeatable instantiations in a highly predictable manner by just using your template file and then changing the parameters. So you can create different flavors, different versions of it. So this is a very powerful concept. So otherwise what would have had to be done without this option was that somebody had to manually go in and create all of these things or write some script to do this. So all of those things have been automated. Now let us go ahead and deploy our application. So the application is modeled in the myapp.yaml file. It is basically a virtual machine with some storage attached to it and then at runtime we will specify what network it has to be connected to. So myapp environment, let us call it myapp1. So all of the runtime parameters are right here and then we have specified that we want this particular application to be connected to the network named rednet in the virtual private cloud that we deployed first. And then we have also specified that we want one gig of storage. Now when we click launch, again here is going to do all the dependency mapping. It figures out that the network already exists based on the reference and then it creates the instance, it then creates the volume and then it attaches the volume to that instance. So it has done that. Let us now go ahead and look at the network topology. So you can see here that as we have specified the application has been deployed myapp with storage and connected attached to the rednetwork. So let's look at this instance details. You can see the flavor, flavor ID and it is attached to a network with the IP address that you have specified and then volume of, you know, one gig has been created and attached to that particular instance. So using this model you will be able to create another instance of the application and attach it to any other VPC. So in that way once you have two components of the application can be now easily customized and manage the way you want to. So that concludes the demo. Let's go back to our deck. So now what you have seen is the declarative modeling approach where what I did was, all I did was to create that specification file and identified the inputs that I need to and then send that information over to the heat service and the heat service did all the real work for me like creating all the stacks and then I was able to just observe the output and see basically confirm whether it has been deployed to my specification or not. That's pretty much straightforward rather than creating all of these resources manually. So last slide and then I will open it up for questions. We have 10 minutes. All of the files, ML files, the local.conf if you want to create a stack of your own and this deck are available for download at this URL. Feel free to download. I've only shown you a small snapshot of the files but you can download and examine and play around with it and extend it as you want. So thank you. If you have any questions, feel free to ask. Yes, yes. So what, so within the template when I created the first network the network was called RedNet and when I created the second network I named it RedNet1. So when I created the application I specify the network and within the network I reference the RedNet of the VPC that I created first. The RedNet1 was the network that I created. So both are two different networks. So he figured out that I have to deploy it into the first VPC. The RedNet, okay, you can see that. Let me just go back if you want. I can show it to you. It takes a while. All right. So when I created the VPC, the first VPC it's even better to visualize here the network topology. When I created the first VPC I created RedNet and BlueNet. When I create a second VPC I created RedNet1 and BlueNet1 and when I created the application I specify that I want the app the instance to be connected to RedNet. So I can create another one and deploy to RedNet1. You can see that coming up. Any other questions? Yes, exactly. So all of the operations are stack operations. So if you want to modify this stack you will have to modify the template. So you go ahead and take the same old template change the RedNet to BlueNet or assign a different name and then send it down to Heat and then do a stack update operation. So there is, if you go to the stack section there is an operation here named changeStackTemplate. So you click on this and provide your modified template and in the modified template you just modify the resources that you want to change. The Heat is intelligent enough to say okay I have all the so you have to specify all the resources in the previous template and only change the resources that you want to modify. The Heat is going to do a comparison and say okay this particular resource change let me go ahead and change it. So it will do stack operations and update it. It won't delete the stack. What it will do is it is going to look at the resources in the new template that you have provided and each resource has an identifier a resource name and the properties. If the resource name and the properties are the same Heat will say that you want to keep that resource it's not going to delete it. If you delete the resource from the stack and update the stack to the Heat send it then it will say okay you deployed Network1 before now you don't want it it's not present in the stack that is how it infers that you want it to be deleted or if you change the property of the network Heat will figure out okay previously I defined created the network as RedNet1 and now in the new template you have specified let's say BlueNet for the same network it's going to delete that RedNet and create a different network. So it infers it based on what you have specified in the template. Stack ID is going to remain the same. So if you don't specify a resource when you update the stack Heat will infer that you don't need that resource it's not going to delete it okay okay so okay I will repeat the question otherwise you can go to the mic so the previous question was how do you modify a stack after it has been created let's say you created a virtual private cloud and it has a red and blue network now let's say I want to change the red network to a different network right how do I do that the answer to that question is you have to create a different template and whatever resource that you want to modify you just update that in the template but leave the original resource that you don't want to be modified intact so Heat is going to compare the current template with the old template and figure out what changed and make the appropriate changes okay any other question yeah so the first question is is it supported through API or SDK yes all of these are API operations so what Horizon does here is that it makes an API call this using the heat client and then sends the template that you have defined to the heat service that is running at the back and so it's all API call this this is just a front-end representation to you and then it is going to pull and retrieve the stack update from the service and the second question was is it supported in kilo release yes I'm running a kilo release but in the previous releases previous releases are not quite stable yet personally I wouldn't recommend it at least Juno should be fine but not beyond before that yes that is possible so the question was can you create dependencies between the my app and VPC essentially what we did was to create a dependency here so let me now if I go ahead and delete VPC one there is an error it won't allow me to do that if you go ahead and delete it it will say cannot delete it it will fail see delete failed because it delete failed because of the dependency mapping my app has been connected now to VPC you can't just delete the VPC so that dependency is created as soon as you deploy the app so if you want to delete this VPC you have to first go ahead and delete the application delete stack it will clear out the application and then you can delete the VPC yes so here is the hand first yes so I have been in fact involved with TOSCA so TOSCA is a very application oriented definition of the language whereas this heat is largely an infrastructure level representation it is not directly support TOSCA to heat what you can essentially do is you should be able to write a translation or some sort of a program that can take a TOSCA's and convert that into a heat representation you may have to break down some of the components when you say in TOSCA MySQL you may have to either create a heat resource which is compatible with that in heat you can create a specific resource your own resource and then specify the properties for it so you will have to do all of those mappings before you can deploy a TOSCA template so it will require some work but it is doable I think it is a good exercise there was a question oh yeah so that the reason is actually in the heat logs so you will have to look at the logs to see exactly it will tell you that it delete fail because of the exact specific reason yes so the question was is it possible to manage OpenStack services OpenStack services okay so services outside of OpenStack using heat you can in fact heat is plugable so it will require you to write some heat plugins and then you know make that plugin to manage that external resource that you want to manage maybe if you want to manage AWS VM creation or a DHCP service or something other it is very much possible so you will have to write a plugin and then heat will use that plugin to manage that external service okay there is one more question so the plugin to extend the capability of heat is unfortunately not in this introductory session maybe I can have probably in the next you know OpenStack an advanced session to illustrate that capability so yes it is possible it requires some work and in fact a few people had demos here showing exactly how that plugin was written to manage an AWS resource you know you can watch the session video too because that is more of an advanced concepts okay any other questions yeah IBM yeah so the question is can you explain how a service chaining works and how IP address is assigned so the point here is that when you create that specification right you are defining it depends on what you are defining as a services first I deployed in my case VPC was the first service right and I deployed that VPC service so I deployed it manually to keep it simple so there is another option called chaining of these templates that is a more advanced topic where in heat you can specify you can actually link or compose one service inside another so in which case it's kind of service chaining you can talk you know you can describe it in any way their template composition or whatever that is I view that as service chaining you can define different services and change them together and create a larger template so that is also possible more advanced topic in heat I think that's in kilo release they have started off with it but I would like to see some more improvements before using that service chaining or template composition and production yes okay the question is HP and Huawei had made a similar proposal and whether I had any intentions of combining so here this is not a proposal this is an introductory session to heat where I'm basically my session really shows you the various capabilities of service modeling declarative modeling concepts right this is not something that is totally new this is there in heat today the what I work I did was basically tie things together into two services two specific concrete services that you can deploy that's all this is not a proposal of anything you know this is just basically an introduction to how you can create and manage services in heat so I think we are out of time 1242 so thank you all appreciate it