 It will take, I'll explain next week. Okay, very good, good morning to all of you, and welcome to the session. So I am Kanak and my friend, we both from Huawei, and we work in OpenStack heat. And we are core viewers. In this slide, I just captured the things required to prepare. So we have two parts. The first part is the learning, and the second part is the tutorial. So during the learning time, you can prepare the setup. So it will take 30 to 40 minutes. So we can utilize properly. Hope everyone got the details. So the same information is available in the etherpad, like asked in iPhone heat. So we can get it from there. So moving to the next slide. I hope everyone having the details. I'm sorry. Slide I'll upload at the end of the session. Just keep in note of the asked in iPhone heat, etherpad link. So that has the same detail. Okay, that's a common thing, like installing the DevStack, like clone. No, just clone the DevStack with that local osc file, whatever is given. So I will move to the next slide. I hope everyone having the detail for the setup. So today, we are going to see the overview of the heat and more detail about the heat orchestration template, schematics, and how we can validate. And we'll see more detail on the heat features of autoscaling and software deployment and configuration. Okay, I'll just go back to the slide. Okay, I'm expecting everybody aware of the DevStack installation. I'm sorry if it's not. So for a DevStack installation, you need a local osc file. So I kept the required local osc setting in that second link. So we can make use of that for installing the DevStack. For installing a DevStack, just Google for DevStack. So it will just give you one link to clone your repository. Once you clone it, you can make use of the local osc to start the installation. It's very simple. Yeah, you just download, keep it with you. And during the tutorial session, it will be required for you. See, first is the image, which is required for tutorial. And second link gives you the detail on a local osc file required for the DevStack. So everyone knows heat is an orchestration service for the open stack. So by using heat, you can bring on the top of open stack, you can bring anything as a service. So anything can be anything. So heat mainly helps to orchestrate and it supports the life cycle of that application, cloud application. So for model the cloud application, heat provides the template. The template you can be in the JSON on the YAML format. Okay, so when you provision each cloud application, heat represents as a stack. So once you model the cloud application in a template, you can provision as many stack as you want. It's similar to AWS cloud formation service. So heat uses its own native template. It's called heat orchestration template. It has its own schematic. And in this session, we'll be learning more about that schematic. So it has a different sections and parameters, and it helps to input the template. And it has certain intrinsic functions, which help you to manipulate or reference the data across the things in the template. And it has environment, resource type, and it has the support for the prototype template. So we'll see more detail about each of this section in detail in the following PPT. So let's see about the schematic. The first thing required in the hot template is the heat template version. So the left side, it will give the details about the each section. On the right side, you will see the sample template, how we can form it. So far we have these many versions supported in the heat. So the first thing what you do when you're creating a template is that heat underscore template underscore version with whatever the template version you want to use. So usually the template version will match with that release date almost. And second section is the description. So description part, you can capture all the detail about the template, the purpose of the template. So suppose if you're using it for deploying something, you can capture the detail about that in the description. So the second section is the description, where you can mention about the purpose of the template or some prerequisites to use the template. What are the things you want to give detail about the template? You can keep it in the description section. And third section is the parameters. And so it helps you to get the inputs from the user and then use it in the template. So parameter have its own schematic. So parameter section will have a list of parameter. And each parameter will have all these attributes. And type is the important, I mean mandatory attributes. So type can be string or it can be a number or even it can be a JSON format. And if you have a list, you can give it in a comma separated list. And even it can be a Boolean value also, true, false. And second thing is the label. It's basically, it's a human readable naming. You can give it for the parameter name. And if you want to give more details about the description, like how you are giving description for the template in detail. So for a given parameter, if you want to give, you can give as part of the description attribute. And say one of the parameters is the flavor. And if you want to keep the default flavor value in the template itself, so you can use the attribute default. So once you assign the value in the default, it is not mandatory for the user to give the input while creating the stack. So the heat will go with the default value represented in this parameter section. And there is a special attribute called hidden. So the moment you mark the parameter as a hidden, say password. And once you give the input, suppose if you want to see the value of that hidden parameter, it will just mask and will just source. So anywhere if you want to hide, I mean, password kind of parameter if you want to use, you can use the attribute hidden. So you have a parameter, and if you want to validate it, the value, whatever you are giving. So you can have a constraints list. So constraints can be, there are some default constraints given by the heat itself. So you can have a length. We'll see more detail in the following slides. So you can have a length or the range or the allowed values. Even you can go with some custom constraints. And you have immutable. You can set it as a true or false. So once you set it true, you cannot change the value. So on the right side, like in the sample template, let's say you have a flavor. You can set the type string. You can give some description. Give some default value. So when you look at the constraints, it has something called a custom constraint, nova.flavor. This is already implemented in the heat. So you can make use of that. So when you set the custom constraint to nova.flavor, when the heat validates the template, it will check whether the given value is proper flavor. Otherwise, it will fail it. So similarly, you can have an image volume size. This is a sample thing. So it depends on your template. You will have the input parameters here. Say your template is huge and does many things. And you want to group the parameters into your groups. So you can make use of parameter underscore groups. So it will allow... You can have as many groups you want. In each group, you need to see the list of parameters it's grouping. So you can say like VM inputs, it groups the flavor and the image. And then volume inputs, it groups the volume size. It's not the real-world example. It's just to show how we can use the parameter groups. So we have like... So far, we have seen like we can tag the template the required version, the schema version. And then you know how to keep the purpose of the template in the description. You know how to give the inputs for the template. Now we'll see how to model the cloud application. So the moment you say modeling the cloud application, it involves so many resources. You need to bring them together and declare it here. So for that, we have a section called resources. So under the resources, you have a list of resources. Like parameters, the resource also have its own list of attributes. So one of the important thing is the type. So type will tell you like whether it's a nova instance, whether it's a Cinder volume or it's a glance image, etc. It has its own way of naming the type. We will see in detail later. And obviously like each resource will have its own properties. So properties will have a name value pair. And you can associate metadata with the resource. So in heat, you can keep metadata for each resource part of the template. And it has a special flag called depends on. So using that, say you have a template, you have hundreds of resources and there are dependency among those resources. We can hard code those dependencies using depends underscore on. And we get two more policies like deletion policy and update policy. These two attributes helps how you want to delete or update the resources during the operating, like deleting or updating. It's very specific to the given resource. Say you want to control like during the update, you want to handle in specific manner according to that resource type. You can keep them under the update underscore policy. So in a sample template, say we have one instance. When you look at the type, it's OS double colon nova double colon server. That's the way you can represent the type. So first we'll have the OS is the provider, whether it's AWS or the OpenStack. And then second part will have the respective service. And the third part will have the actual resource. So you have a list of properties. So in case of server, you are seeing like image, flavor, like, depends on the type of the service or type of the resource, you will have its own properties. So say you want to attach a volume with a given instance. So you will be having one nova server type and one cinder volume and one cinder volume attachment resource. These are the three resources you'll be having in your template. So now you model your cloud application part of the resources section. So now you got the input, you modeled it. So when it is created as a stack in the heat, obviously you want to get the output from it. So you are deploying your own web application at the end of the day. Once it's created, you want to return the IP address port, the URL. So you can keep them in the output section. So outputs again, it will have a list of outputs and each output will have the description. You can assume what is the purpose of description and it will have the value. So if you look at here for the instance, so you created one instance with the volume and attached to it. Now you want to give the IP address of the instance created. So you can keep it in one of the output in this template. So now we know what are the different sections and what each section is meant for. So we'll see in more detail in the following show. And we saw the parameters. It has the parameter constraints. So as I mentioned earlier, there are inbuilt constraints as well as the custom constraints. So length is one of the inbuilt constraints. So you can have a min and max value for it. And similarly, if you want to keep the range, also you can keep it using the range. So again, it will have a min and max. And allowed values, say you want to validate the given input parameter against the list of values it can hold. So you can use the constraint allowed underscore values. And similarly, if you want to validate the input with the given rejects, you can go with allowed pattern, allowed underscore pattern constraint. So on top of this, he provides these many custom constraints. So if you look at custom constraints, it will be given for each service. So every service will be given with a list of custom constraints required. So on top of that, sorry, it's not highlighted here. For example, ip underscore addr and iso underscore 8607. These are all not service specific things. Some utility constraints also provided by heat. So all this information is already available over the internet. So I will share you the detail at the end of the session. So on top of this parameter, heat provides something called pseudo-parameter. So these are the pseudo-parameters. So if you, anywhere in the template, if you specify like OS double colon stack underscore id, you can get the stack id. Sometimes it's useful when you are doing auto-scaling, this one. Similarly, you can do it for a stack name or the project id. So say you have created a stack. Once you created a stack, you want to see the value of this pseudo-parameter. You can just do open stack so. So it will show you the value of these parameters. You can get it from there. So heat provides an intrinsic function. Its main purpose is say you want to reference across these resources or you want to do some data manipulation or you want to reference the input or the output within the template. So for all this purpose, the intrinsic functions are implemented. There are so many intrinsic functions. And so this slide captures like for each template schema version. So what are the intrinsic functions supported so far? So if you look at here, the down part is the AWS way of convention mentioning that. Okay. Almost when heat was introduced, we had a very similar to the AWS convention. Okay. And today we have similar functionality with heat native functions. So in the top highlighted all only applicable for the hot template. And so if you want to know like the given function is when it is when the support is enabled or whether it's available, support is available in the given schema version, you can refer this table. So for example, when you use the second version, 2014, 10, 16, obviously you cannot use digest or repeat intrinsic functions. When you are using the latest one like 2016 408. So it's the Mitaka version. So it has all the support. I mean, in this template, all the intrinsic functions are supported. And almost all the AWS way of using the intrinsic functions or support is removed. So let's see more detail on the each intrinsic functions. Okay. The first category is referencing the data across within the template. So first is the gate file. Okay. So what is the purpose of the gate file? So when we are creating the templates for a deployment, you will be having with the template, you will be having so many additional data which might be captured in the files. Let's say config information, some script. So all those things you want to get the, I mean, refer and get the value of these files within the template. So that's where you can use get underscore file. So in this case, for the NOVA server resource, for the feeding the resource data, you can keep the user data in a separate shell file, and then you can just use this get underscore file to refer it. So it will help you to bifurcate the things into the different files and then make templates simple and maintaining easier. Okay. Say, when you are creating the stack, you are feeding with the file user underscore, sorry, userdata.sh, and whatever the value you are feeding there, and he should be able to use in user underscore data properties. Okay. So for that, whether you are using the CLI or the REST API, so he provides a section called files in the STTP request. So when you are using the CLI, CLI will read the data and then keep the map of full path to that file and then actual content. So once these files map go as part of the request to the heat, so heat can easily refer across. Okay. So next is the heat, sorry, get underscore param. So this one helps, so we saw like there are parameters section helps to feed the input. So once you define all the parameters, you want to get the value of it in the respective resources. So where we can use the get param. Okay. So in this case, take the example like instance type and we have server data. There are two input parameters. Okay. So it's getting used in the resource my underscore instance. So the flavor, you can get get underscore param of the instance type. So in the red color. And if you want to get the metadata, you can, you can set from the server underscore data. So in the session, you can capture like key value pairs. So whatever is there in the server underscore data within that whatever is metadata, it will be assigned to metadata properties in the instance. Similarly, you can use the key name. So if you look at here, so you can use the get param for referring as the key, like key value, or even you can take a list from there, you can index by numbers. So heat param supports both. Sorry, get underscore param supports both the convention. So when you, when you feed the input with the, with these values and then so the same will be assigned here. So the one over the flavor will have a mn.tiny and metadata will have like full bar and keys will have a underscore key. So now we know like get underscore param. You can use it with the map as well as the list. How we can use it. Okay. So, so for reference, you have two things. So for mainly for the input purpose, get file and get underscore param. So, and there are many manipulations, functions, data manipulation functions given by the heat. Let's see one by one. Okay. So it's a map match. So you have like a two map. So and you want to match them together for some purpose. So you can go with the map underscore match. So when you, so in this case, let's say like a k1 v1, k2 v2. And again, you will have like a k1 v1. So it will match them together. So final result will be on k1 and k2. These functions will be very handy when we are, when we hit the situation where we need to manipulate the data within the template. Okay. So again is the string str underscore split. So first is the splitting character. Want to use whether your comma or a colon, whatever it is. And second is the actual string. So it has, it is taking the indexing also. So once you split, if you want to take the given indexing, say data at the position zero or one, two. So you can mention it as a that parameter. So it will give the result. So in this case, string to split is separated by the comma. And we asked to give the first string. So it gives the value string. Okay. The next one is str underscore replace. Okay. So it has two properties. One is the template and there is the params. So in the template, you can keep the real string, whatever you want with parameterized. So if you go to any language, it support parameterizing. So the parameterizing the string. Okay. Similar to that. So we can do in the template. So we are having here like a host colon port slash v1. So in the parameters, the value are giving like with the IP address and the port. So finally we'll give the, it will give the result of the actual URL with the IP and port. So for example, I just assigned the value for a host and port here. So those value come from any different place. It can be like a gate underscore param. So you can say like, you can get these two values from the user and then you can use gate underscore param of IP, gate underscore param of port. So we can use like that also. Okay. The next function is the list underscore join. Okay. Like a str underscore split helps you to split and then get the required values. And list join is like joining the given list to one string. So first is the character to join. And we can have as many list of, as you want. So it will join all of them together using the first character, whatever you're given. Okay. Repeat is like a for function in any language. Okay. So it has the for underscore each. And it's like nested loop kind of thing. For the first line of a, you can keep as many for underscore for underscore each. You can keep as many nested you want. So for, we know how nested works, right? So for feeding the value for the parameterizing. So it is the template as the value given in the template. So in this case, we have port on protocol that's given with what are the values given in the port underscore range underscore min. So when it is going through the looping, the result will be like this on the right hand side. So the protocol on port underscore range underscore min, you have four sets with what are the value you're given. So for manipulating, we have like four or five functions. So you can like a split or join, or you can repeat, or you can merge. So and we have a utility function called digest. So basically it helps with different hashing algorithm. So it supports with what are mentioned here. This many hashing support is available now. Okay. So now we know how to get input parameters, input values, and we know how to manipulate things. And we saw some utility functions for digest. And now we'll see the dependencies reference function. And these functions will be mostly used in any, even given some simple template. Okay. So get underscore resource. Suppose one resource is depending on another. Say for creating instance, first you want to create a flavor, or you want to create the network. So for creating flavor, you may have one resource in the template. For creating network, you will have another resource in the template. So once those two are created, then only we can go for creating the instance. So that is the requirement. We can make use of the gate resource. So if you look at here, for the port, it is getting the value from the instance underscore port. It's highlighted in the blue color. Okay. So when we are mentioning like this in the template, heat will know the dependencies between them. It will make sure that first instance underscore port is created. And whatever the ID it created, I mean the port ID, you can get the ID and assign it to port in the instance resource. So for that purpose, you are using gate underscore resource intensity function. So we saw one like a depends underscore on. So that's a hard code way of putting the dependencies. And when we are using gate resource, heat will itself will make the dependency among the resources by itself. Second is the gate attribute. Okay. So you have a resource. And once the resource is created, and each resource will be given with a set of attributes. If you want to reference that attribute, we can make use of the gate underscore ATTR. Okay. So in this case, say we created the server, and we want to output the server private IP address. So we can make use of the gate underscore ATTR. So we can use two way like how we saw in the gate underscore param. So we can directly reference by given key, or if it is the value is the list, you can index by numbers. Both are supported. Okay. So there is a special intensity function, say, usually like when you are referring like referring one resource or another resource as output. But suppose when we are having multiple templates, and we'll see more about that provided template later in the session. So in heat, what we can do? We can biproquet the templates into logical templates. And so there will be one parent template, and within the parent template, you can have a child template. So all the child templates, you can call it as the provided template in heat. Okay. So in the parent, see the example of parent template, it has the metadata update policy and deletion policy. So from the parent template, you want to reference these values in the child template. So you can make use of this resource underscore packet. So with this function, only these three attributes are supported today. So metadata update policy and deletion policy. Okay. This is not the intensive function, but it helps you to make the dependency among, depends underscore on. So this is a, as we know already, it's like a hard bound way of telling that, okay, one resource is depending on the other resource. So once you mention that the dependent underscore on for a given resource, so the heat will make sure the dependency among them. So in this case, it will try to create the instance two on three, then only it will go for creation of the instance one. So now we know like the purpose of intensive function and what are the different kind of intensive functions available. So to summarize, so you have data manipulations and you have functions for a digest. So you have functions for referencing across and you have functions for like getting input as a parameter or the file. Okay. Let's talk more about the resource type. Okay. So we know, right, the resource type is the one which is mentioned, the template, another resource section. Each resource will be tagged with that type called resource type. Okay. So what is a resource type? So if you take any service, takes a NOAA as an example. So NOAA has so many entities supported. So like a flavor or the server, et cetera. So if you want to model each of these entities, we can go for a resource type. Okay. And not only that, suppose if you want to, in your use case, if you want to implement your own proprietary things, you can implement your own resource plugin for it, for a given resource type. Say like OS double colon, say demo colon, blah, blah. Then you can implement on resource plugin and then put it in the heap. We can make it soft in the template. So basically it helps to model the entity of a given service. Okay. So it's always represented like, first part will be the cloud provider like OS or AWS, then the service name followed by the actual resource. Okay. So every resource type has its own supported lifecycle. Okay. Heats supports, we know right, heats supports the lifecycle of the stack. So correspondingly for the lifecycle of the stack, we will have a respective lifecycle things in the resource type. So you can create, update, delete, or you can snapshot or restore. And then you can do some check, stack check. And then you have abandoned and adopt. Okay. So while we are seeing about the schematics, we saw that each resource have set of attributes. So and it has attribute called properties. Okay. So properties will have a list of property and each property can have these attributes. So each property will have its own type. As mentioned, it can be like integer, string, number, et cetera. And we can say whether the property is updatable during the stack update. If it is not updatable, you can mark it as no. Default it is, every property is updatable. And default, every properties are marked as not required. So if you feel that property is required, then you should mark it as s while implementing the resource type. And it has, it's like a metadata and where you can associate resource with the given list of metadata and then deletion policy, update policy. We know the purpose of these policies already. So take the example of the resource type server. It has a properties and then the properties will define, like this image is the property name and its type string concerns its clients.image. Okay. This is the schema for this resource type. So when you are using this resource type inside the template, so you can use like this. So type you will say whatever is the type given by the schema. And under the, whatever the properties it is there, okay, I'm sorry. Here the image will come under the properties attributes. There's a mistake. Similarly, each resource type will say like when I created, I can give this many list of outputs. Output also we can tag with type. And there is a special attribute called show. So when you use a show, what he does, so say like get underscore attribute of show, like in this case sample. So if you use that, what he does, it will get the actual properties of that sample instance from the nova and give it back to you. Okay. So OS or nova server defines the attributes called first underscore address. It's of type string. So if you want to use that attribute in the template, so we can use like that. So we'll use the intrinsic method called get underscore ATTR. And then you can use it. Heat provides something called environment. Okay, so if you want to customize your template specific to your environment, say whether you have a test environment or the production environment, if you want to customize, you can put all those customization environments. So heat itself is as its own predefined global environment. So you can define that in the heat con file under the environment underscore TR. And if you want to give your user specific environment also, you can feed. So when you are creating a stack, you can give the environment file. So heat will make use of that environment file. So when you are using the heat stack create, you can give it a parameter. So environment has the section like we know in the template has section called parameters. Similarly environment has the section called parameters. So in the parameters you can mention like say in your template you have flavor and image. And in your environments you want test environment, you want to use different flavor image and then production environment use different flavor and image. So you can capture them under environment. So when you are feeding this using the iPhone e parameter and heat will automatically take the values from it. Next is the resource registry. Basically this is where you can do the customization on the resource types. So if you know like in past we have quantum as the network service and then it named to the neutron. So during that time so if you have a template with OS quantum and if you want to map them to the neutron resource type you can customize in the resource registry. So that's called resource mapping. So next is the overriding the resource. So for a given resource type you have a default implementation and you want to override it for your purpose. So that's also possible here. So under the resource registry you can give like what is the type you want to override and next to that how you are going to override. So here we given the path to the one YAML file. This YAML file is the provider template path. So whenever you are using this awsec2 instance so it will make use of the provider template as the resource type. So the path can be either file or it can be a URL or it can also be with STDP. And there is a convention that the template should be either with dot YAML or it should be with dot template. Also you can override for a given resource name in the template. So if you want to say like a db underscore server you want to customize it. You want to override it. You can override like this. So either you can override by the type or you can override for the given resource in the template. So currently we are supporting update and replace. So when you are updating a template, sorry updating a stack, say you want to restrict the update for a given resource. So you can restrict by using restricted underscore actions. So wherever the db underscore server you mentioned in the template and those resource will be restricted with update and replace. Both accents will be restricted. For the restricted actions. In generic, suppose you want to stop the update. You created the resource. For some purpose you don't want to update. You don't want to allow the update. So in that case you can go with the restricted actions. Maybe I will give you the real use case maybe later. Let me find and give you. And underneath we have hooks. So hooks basically whenever the resource is created, so you want to do something before and after creation. It's more of like the Tosca template. It has life cycle actions. So similar to that here if you want to do some actions before and after you can make use of that. So you have pre-create, update, delete. Similarly post-create, update and delete. Okay. So you can use like the actual resource name or you can say like with the regular expression with star. So whatever the matching with star underscore server all of them will be applied with these restricted action hooks. Whatever mentioned here. So we have events as another feature in the heat. Suppose today what's happening when you are creating a stack. So all the events is going to the heat database. And then you can query by stack events. Okay. Instead of that say you want to listen for the events over the RabbitMQ or over the messaging service. So you can make use of the syncs. So each event sync has the type and then you can say the target. It's a queuing name and then TTL is the configurable parameter in it. So earlier we saw like part of the session we saw the use of the provider template. So it basically helps you to bifurcate your bigger template into smaller logically. So it helps you to easily manageable. Okay. More on that resource type you can, sorry, using provider template you can create the new resource type. For example in the environment when you are seeing the environment slide earlier so we saw that, okay, you can say one resource type and then you can override by the provider template. We saw it right in the earlier previous template. So that you can do with the provider template in place. Okay. So you can reference the new resource type directly either by mentioning the provider template itself. So in this case whatever we have done we have one provider template and we are directly referencing this by the name, file name. That's the one way of doing it. So another way of doing is using the environment. See in the earlier slide environment you can say this is my type and this is my provider template and when you are using that you can, when you say type like OS NOVA server you can use of the actual plugin implement the heat. It will make use of the my underscore NOVA YAML. Okay. Let's see how we can access the attributes of the template resource. Okay. So in this case say my underscore NOVA is the provider template and the left side whatever you are seeing is the parent template and you want to get the attributes from the resource in the provider template. So by making use of the get underscore ATTR you give the resource name followed by the resource dot whatever the resource in the provider template and then give the attribute name whatever you want to access. See for example when we look at in this case what we have done as an example for the OS NOVA server instead of using the actual plugin we model with the template. Okay. So once you created this template whatever in the left hand side so it will actually create the server. Okay. Okay. So when you are creating the server say you want to see for example you want to get the ID of that server. Okay. So when you are seeing like OS double colon stack ID when you are assigning it actually you are getting the server ID. If you don't assign like this so the OS underscore stack ID will give us the stack ID of the parent template created. So transparently if you want to make the resource ID available like this we can go with it. So far we know like what are the different schematics of the hot template and we saw in detail about each of them. Okay. So you created the template every time when you are creating the template you will get into so many issues. Okay. So to validate the template heat provides its own command so either of these two command you can make use of it for validating it. So we have a legacy command heat template if invalidate and then you can give the template file and the same feature is enabled now in the open stack CLI. So you can go with the orchestration template validate. So either of these command perfectly work in the metaka so you can make use of it. Okay. So you created the so you created the template and by making use of these one of these command you can validate it. So once it validated as a output so as part of the output of this command you will give the list of input parameter for this template. It will tell like what each input parameter what is the type and what each input parameter. Hold for and the preview so before creating a template it's better to run this command to see the preview. So when you're running the preview you will come to know what's going to happen when you're really creating it. So it will show you the almost all the attributes of each resource as part of the template. So now we know what is the heat orchestration template. Okay. By using the heat orchestration template every feature parameter in the heat is implemented. Okay. So using the resource type heat implements the auto scaling. So auto scaling is like say in a given scenario you want to scale up or scale down based on your criteria. So you can go for the auto scaling. Software configuration deployment helps you to deploy your applications via heat. So and we have a resource grouping. Okay. So for the same resource you want to create in numbers say like a stand 20 you can go with the resource grouping. And remote stack it helps you to do the stack creation across the regions. Okay. It is some special resource type called a non-resource. Okay. Like as programming like as for some reason you can mark a variable equal to none. Similarly you can make resource using the resource mapping. You can sorry resource mapping or you can call resource overriding. In the environment you can say the given resource type you can overwrite to non-type. So basically it does nothing. During the testing so you want to mask some types you can make use of it. And it gives the random string as the utility resource type where most of the time when we are generating the password we would be expecting the random password so you can make use of it. And weight condition mainly helps during the deployment so you created some you started to create a resource and you want to you don't want to wait till the resource is created by the backend. So what you can do we can make use of the weight conditions. Okay. So when backend creates its resource it can signal back to heat. So for that you can use the weight conditions. So and using the environment as we saw already we can make use of the heat sorry hooks for doing some pre or post lifecycle operation as well as we can make use of for the break points. Okay. So out of these features spread by the heat so we will see more detail about auto scaling and software deployment as we go forward. What's the time. So hope now you all will be having the setup ready. I'm not sure. So usually desktop take 40 minutes to one hour. And image is downloaded. Okay. So we'll okay then we'll take some more time we'll go through the auto scaling and software deployment. Okay. And end of the session maybe we'll see the thing. I'm sorry actually I try to give this play request before all of you coming here but I failed to find the way how to do that. If not everyone is having like a desktop setup maybe like who is having maybe group together. It will be helpful. Okay. Yeah. I have a setup I can show you like during the demo. But it's good to like if you have your own setup it helps to learn. So one way is like we can group and then who is having we can go with it. So now we'll before going to detail about the auto scaling like to take questions if you have. Okay. So let's see more detail about the auto scaling. So auto scaling helps. I'm sorry. Yeah. I'm sorry. I failed to hear. So obviously you are changing some detail about the resources. Okay. Okay. So when doing the stack update it will try to see what is the current state of the stack and whatever the update or whatever you are given. So whichever is the resource required it will see those resources are required update and it will go for update. So one resource does not require any update it does not do anything. Right. Okay. So your question is like for a resource one you mentioned the restricted action as update then it won't allow you to update. So it's basically helps you to control however you want. Okay. So auto scaling helps. So basically you will have resources and obviously resources will be like compute storage network for a given scenario you want to like scale down or scale up you can make use of the auto scaling. So the moment you say auto scaling somebody has to monitor your resource and then when it's reaching your pre-defined threshold it should tell to hit that okay the threshold is reached. So basically auto scaling is implemented with heat with one of the monitoring service is a solimeter or a monoska. It has four or five resource type for the auto scaling. Okay let's see auto scaling based on the monoska. So first you will define the scale group. The scale group will have the resource it needs to be scale up or scale down. So you will have then decide capacity. First time when I am creating I can tell okay I want two instance or I want say ten instance. How many resources I want in the scale group. You can mention in the decide capacity. Obviously then you can set the max and the min boundaries. So when it's scaling up say you set for like twenty it won't go beyond twenty. So when you are setting the minimum size is five it does not go beyond five. So you can control the size of the scaling group. The initial size how much it can grow or how much it can shrink. And it does gives the outputs attributes. So using the current size you can get what is the current number of resources in the scaling group. And scale group has list of resources in it. And you want to see the output of all these resources in that group. And make use of outputs. So it will give you the map and outputs list it will give you the list. So the next is the scaling policy. So how do you want to scale during the even happen. So when I am scaling up say I want to add two instance say I want to add only one instance or I want to add like three instance. So how much I want to adjust the scaling group. So all these things you can capture in the scaling policies. So the scaling adjustment will have plus or minus. Or I can say whenever I am hitting the threshold always keep my number as given number. I mean given n. Say I always my count to be 10. You can set like that also. Or I can say in percentage. And it has something called cool down. So basically the or the will intimate heat via the scaling policy. So when the signal comes to the heat. He does should know like whether I can proceed for the scaling. So we can control that using the cool down. So it's basically a timing window. Say now I am in a progress of scaling. And one signal is coming now. I should not do the scaling. So when you are designing the template we know how much time approximately it will take for scaling. So based on that you can set the cool down time. And it has auto scaling group ID and it will be referencing the auto scaling group. So it has two outputs. One is the alarm URL, another is the signal URL. In heat you can signal the stack either via two APIs available. One is the CFN API, another is the heat API. So however you want to signal the heat. So you can make use of one of these attributes. So this scaling group and scaling policy is common across whether you are using the monoska or the salemeter. Okay. When you are using the monoska you will have a notification as a third resource. So notification will have the address. The address is nothing but whatever the alarm or signal URL you created as part of the scaling policy. So unfortunately the alarm definitions. Okay. This is the one it's going to define you in the monoska. What is the threshold I am setting for my scaling group. Okay. I can set it as a scale. So let me make when my scaling group reaches the CP threshold of this much either you do scale down or scale up. So whether you want to scale down or scale up, you can do it in the alarm accents. So if you want to scale up, you will be having one policy for scaling up. So this alarm definition will have reference to up scaling and you will have another threshold definition. Okay. And it will have its own scale down policies alarm URL. So these are the four resource type you will be using in the auto scaling. Okay. So once you model this auto scaling template and created it, heat will create the stack. Okay. Once the stack is created, it should be created. So while monitoring, the open sex should be able to associate between, I mean the bonus cost should be able to identify the resources in the scaling group and then find the threshold among all those resources in the scaling group. So for that, we need to bind the threshold whatever you are defining in the definition as well as whatever it is. So we look at here whatever the resource part of the scaling group will have a metadata called scale underscore group. So there you can keep the stack ID. To get the stack ID, you can use the gate underscore param was double colon stack underscore ID. So that same stack ID is used in the alarm expression. So this is how the monoska binds the metrics collected by itself with the scaling group. So more detail about this is captured in the, I mean expression details captured in this link given here. I will share the PPT, one session is done. And I have demoed the same in the last summit. So there is a video available in the open sex site. So you can watch it. So for salameter is the same, the scaling group, scaling policy are same. There is no difference whether you are using salameter or the monoska. So only difference comes is how you are going to define the threshold and how you are going to trigger. So in case of monoska you will define two things, alarm definitions and then notifications. So in salameter you can mention both in one resource type called alarm. Okay. The difference is how you are going to define the threshold. So monoska have its own way of doing. In salameter having its own way of doing. So how to define the threshold is captured in this wiki. So based on that wiki you can define the threshold using this resource type. Okay. So in this case the alarm actions will have that URL whereas in monoska the notification had reference to the scaling policy. Like in monoska case the binding has happened using that scaling underscore group. So here we need to use the metering.stack as the metadata when we are using salameter as the monitoring service for auto scaling. And in the resource type you need to mention the same stack ID in the metadata dot user underscore metadata dot stack. So this is the difference like when you are using monoska or when you are using the salameter. The rest of things are same. So in addition to that salameter alarm so in heat we are giving additional support. Okay so if you want to combine the alarm you have like so you have two alarms created and you want to aggregate them you can do it. So these are the features supported in the salameter side so all those support already enabled in the heat. So based on your requirement either you can go with the salameter alarm or whichever the alarm resource type suits your need. Okay let's see the workflow. Okay so in first place you deployed the heat monoska the salameter and your deployment is ready. So now you form the template of the auto scaling so you feed it the heat. So what's the heat is going to create the required things in the cloud and then it set up the monoska or the salameter with what are the alarm definition or the alarm or the notification whatever you mentioned in the template. So once this is in place you created the cloud applications and salameter started to monitoring it. So now auto scaling is started. So from this moment based on the threshold you defined in the alarm definitions or the alarm and the monoska or salameter will identify that event happened and threshold exceeds then it will start to create an alarm. So once so something's happened I mean threshold is reached so it found then it creates alarm. So once alarm is created whatever the signaling you mentioned in the template using the signaling policy that alarm URL or the signal URL it will invoke. So those are the webhook in the monoska or the salameter side. So it will signal the heat and now heat will go and do the auto scaling based on whatever you defined the scaling policy. Suppose now it happened like threshold is reached earlier it was 2 vm now heat is increased this to 3 vm. Similarly like now 3 vm's has come up load now the load is reduced after sometime and your lower threshold will be meeting. So once the royal threshold is reached again it will be monoska or salameter will create an alarm and it will trigger the scale down policy. So when the scale down policy comes 1 vm will be reduced. So this how the auto scaling works any questions? Okay we'll move to the software deployment my friend will take over. Okay Lafoyne I will introduce you how to config software on service in your stack. In January there are 3 options we can to do this including custom image building user data both scripts and software deployment. So I will describe each of these options and we give some examples. Okay the option 1 customer image building first opportunity to inference what software is configured on service is by booting with custom build image. I think there are a number of reasons you might do this including boot speed boot reliability or test verification or configuration dependence. Since the required software is already only image so there is no need to download or install anything at the boot time. And the customer image will reduce the failures such as transient network failures and in consistency software repositories. Also the customer image can be verified in your test environment before being promoted to production. And there are a number of tools available for building the customer image. Today in our session we will use the disk image builder. The option to use data boot scripts when a server when booting a server it is possible to specify the content of the user data to be posted to a live server and how the user data is consumed depends on the image being booted. And the most commonly used tool for default cloud image is the cloud in it. So in the snippet of the template for the server resource there are two properties user data and user data format. We can set the boot scripts in user data property and the content should be the shared scripts and cloud config or part handler or others format which is supported by cloud in it. And for user data format we have three values. For the four values hit safe end tools. The user data is part of the state event tools booted data. It is compatible with AWS cloud formation. And for low the user data path to Nova are modified. And for software config the user data is part of the software config data. Okay. Often there is a need to pass the parameters to the boot scripts. So this can be done by the function street replace. And when boot scripts grow bigger and bigger it is difficult to maintain the contents inside the template. So you'd better to put the boot scripts into a separate file and then use the git file to get the content of the user data. Also the user data can be managed as their own resource. And then the Nova server can reference the resource of a config resource. Let's see the base code config resource. Here we have two properties, group and config. For group this property determines what tools will come from the configuration. And config we can set the string configuration to this property. Okay. Here we can use the get resource function to reference the software config resource to use the data property. There is another config resource. In this resource you can only set the config user data in this resource. And also we can reference this config resource in user data property of the Nova server. And sometimes maybe you want to combine several configs together. So there is a resource called the multi-part memory. Such as this resource can combine software config and cloud config together. And then this multi-part memory resource can be referenced by the user data property of the server. Okay. Then we will talk about this. You know the software config resource is used for storing the config data. But this software deployment resource is used to assert the config resource with a server. And this resource runs any number of the software from the server throughout its life cycle. So let's see the software deployment resource. There are several important properties. Config, server, input values and action signal transport. Okay, first the config. We can find config resource and reference the config resource in config property such as the software config. So use the get resource to reference. Okay. The server property, we also get the resource from a normal server. Here we can see light. For a normal server, if you want to use the software deployment, you should set the user data format to software config before you use the software deployment. And for input values, you can assign input values to config scripts. Also to deploy actions. This property decides which action of the software deployment will trigger the software deployment. The last one, signal transport. This property is determined how to signal to hit with the deployment or you can say the output values. Okay. Before you use the software deployment, you must build the customer image first. We can do the steps following. Paper install the two disk image builder and get the elements and export some elements required. Then you can use the disk image create command to build the customer image. Okay. Let's see the workflow of the software deployment. Step one, use code heat API to create with the hot templates. Based on the templates, heat will create config server resource and software deployment resource. When the server is booting, the cloud will consume the user data. Then step four, the engine elements will start to create the configuration from heat. Corresponding hooks will perform the configuration data. Then if the software deployment is done, the tools will signal software deployment resource to tell the deployment result. Okay. This is the workflow of the software deployment. As mentioned, the software deployment runs to any number to software configuration to be added or removed throughout the life cycle of the server. If you want to change the software, you can take the step seven and code heat the API, stack updates with a new template. Then the step four to six will repeat. Okay. So there's some useful reference. And our nickname IRC. So thank you. We tried to capture the templates. We captured the sample templates to learn more about the hot schematics. These are not the real use cases. But we can use this for learning about the hot schematics, whatever we learned today. You can try out some templates now. I think we have 10 more minutes. I followed some conventions. For example, if you go to your template, each template will give the description on how to make use of it. So in some template, we intensely left some errors. So when you're trying, you will see the errors. Then how to fix the errors, we given the steps in the description part. So you can follow it and then you can fix it. So you could see there are sample templates for the parameters or the intensity functions, some other things. And we have given a simple and sample template for autoscaling as well as the software deployment. They're also available here. So the eighth one is the autoscaling template. And the ninth one is the software deployment template. So to use that template, whatever the image you have downloaded, you can make use of it. Autoscaling is a very important part of the autoscaling. So for monoska based autoscaling, we have covered one session in the last summit. So what I will do, I will capture the link for this PPT and that monoska sessions. As well as this session, a URL in the etherpad, whatever I shared earlier, like Austin iPhone heat. So maybe like a week at time. So everything should be available there. So let's try some template. So let us see a template. To be an valid template, so if you have just the heat template version in it, that's sufficient. It's just a valid template. So description part you can, we know now, right, like a description. We can keep all the details for the template. To see what are the template schema supported in a given deployment, heat deployment. So there are commands available. We can just run those commands and then see. For example, in this deployment let's see whatever the thing supported. So in this deployment we have this many supported version. So there are two supported type. One is CFN and then HOT. So we can see like there are like two, three, four, five, six hot schema sensors supported. So if you create a template with any of this template version heat should be able to understand and then take it forward. So this template will help you to learn about the resource type. So for the resource type we have kept there is a link. I mean, there is a documents available over the internet. So we can refer this URL where you will get all the resource type supported in the heat. So let us see how to validate it. I'm not sure how to do it. Let me try. So let's take the initial one. So when you are validating the template you will give the okay, so we hit the error. So I given the wrong template version. So heat says I don't support it. So let's just go and change it to the right version. So now we know like how to get the list of supported versions. So I will just change this to 8. The command, okay. So in OpenStack we have like CLI feature in the command OpenStack. So we have enabled in Mitaka we have enabled for the heat. So OpenStack CLI guide will tell you how we can use it. So when you are using the validate command it will give the list of parameters defined in the template. So once you validate it you will come to know, okay, these are my parameters. I should be aware of it. So let us do the same thing. So for doing the stack preview we have a new command in the OpenStack. It's called dry run. Say let us take the second template where we had the resource type in it. Then give some name the most stack one. So what it does so if you look at here heat will go through all the template and we will try to depict you how it will be when you are creating a stack. So when you use the validate it will give the list of input parameters and when you do the dry run that's called a preview it will show you how it's going to be when you are creating the stack. Okay, let us see some other example. Okay, I will show you the maybe the salameter that is just little bigger. So we'll get one of many things. Okay, I'm not sure the size is okay. So if you look at here we have a list of input parameters like flavor, image and the network and you have resources. So we know like for auto scaling there are four main resources will be used. So in our case first you will define the scaling group with the in-sale capacity and then the range of how much maximum it can go, how much maximum it can go. So then you will define the scaling policy. So for scaling policy obviously we will have two policies one for scale up and one for the scale down. Similarly we will have an alarm definition also. So in our case we are using salameter. So you will find two alarm one for the low and one for the upper limit. So I already created this stack for the salameter. So let's see some detail about that stack. So the stack name is AS. Let us see how many resources are there in that stack. What are the resources you have seen in the template? So all the more like created in the respective backends and those are captured as a resource. So we can see like there are two scaling policies and two alarms and one group. So if you say in our list so in the alarm scaling group I mentioned like the minimum range is 1 maximum is 3 I think. So after I created this stack scale down event is triggered and when the scale down event is triggered it brought the count to 1 from 2. So if you want to know when the scale down is happened, when the scale up is happened so heat provides even list. So when we do the even list we will come to know what happened. So I think I created this quite a while back. So we can see here there are so many like event happened like on the scale down policy so many signaling has happened from the salameter side. So what happened so I created the stack in the stack VM I am not doing anything. So when first it created it was created with two instance so salameter started to monitor those two instance when the threshold come down so it obviously has to down the count to 1. So it was started the scale down to 1, resource count to 1. From that moment keep on monitoring threshold is less than the defined threshold so it will keep on signaling the heat saying that this stack threshold is reduced but when it comes to the heat heat knows that the scaling group minimum size is 1. It cannot reduce beyond that. So how many times the scale down comes once it reaches the scale down the lower limit okay so I think that's all all what session so I will capture the required document details in that etherpad whatever I given please try to make use of it any questions to take yes now in the etherpad I will give the link so you can download from there okay I just captured this on how to make use of the gate file so it does not do nothing much so if you go here so here I have referenced this just for the tutorial purpose I kept it we can discuss in detail like based on the offline okay thank you all thank you