 Hi, my name is Steve Baker. I'm the PTL for the Heat Project for the Liberty Cycle, and this is the project update for Heat. So if we go onto the first slide, we'll just give a quick overview of the general stats of the development pace in the Kilo Cycle. There were 74 blueprints implemented, almost 400 bugs, 1100 code commits from 127 people. So this continues the trend of a well-engaged multi-vendor project. So it's quite encouraging at how much participation we've got in the Heat Project from a number of vendors. So just going on to the next slide, we've got a summary of some of the Kilo new features. So improved scaling using nested stacks. Previously, a stack which had a lot of nested stacks or template resources, operations occurred by loading the entire tree in memory and then processing the stack in that way. We now have an Oslo messaging boundary between every template resource. This allows the resource operations to be spread across multiple heat engines. So that's an improvement in scalability. I'll talk about convergence later, just to describe how the general trend of distributing workloads across heat engines is continuing. We've got some new template functions such as digest and repeat. Digest is just a way of transforming a string into a digest and repeat as a construct for combining multiple lists, transforming multiple lists into a dictionary. We now support multi-region stacks. You can define a resource which provisions a stack on a different open stack region. This will allow you to define a stack that spans regions and giving you more redundancy in your application. We've also got an ability to pause stack creation and update on a given resource. This is a feature which lets you define hooks in your environment so that when you bring up the stack, when it hits one of these hooks, it will stop and it won't progress until it gets an explicit signal from the user or script that it should continue. This has a number of quite useful use cases. You could use it for debugging. In that respect, it's a little bit like a break point where if you want to pause at a particular point in the orchestration to let you go in and manually inspect the state of the stack. It also has use cases for large clusters when you want to stagger the creation of resources. Whether that's to perform some kind of manual validation that the cluster is doing the correct operation before you progress to more nodes in the cluster or if it's just to stagger the cluster changes so that you don't have a stampeding herd of changes all happening at the same time. So let's go on to the next slide now and look at the new kilo, new resources. As usual, we've got a selection of new resources and features to existing resources. We're now supporting Nokia-based Solometer alarms. There's a Cindervolume type resource, which would be more aimed at operators and admins. Similarly, we've got Keystone resources for defining group project role and user. There's also a more admin-focused resource, a collection of resources. And it's highlighting a trend that there seems to be a desire for some operators to represent their backend configuration of their clouds using HEAT, which is an interesting development and something that we will quite likely do more of. We've also got Mistral workflow resource and trope cluster. So let's go on to the next slide and look at some of the planned new resources for the Liberty Cycle. We already have a Barbican resource, but there's some significant enhancements which make the properties a lot richer. Keystone endpoint and service. So this, with those two resources, is now possible to bootstrap an empty Keystone using just HEAT templates. So it'll be interesting to see how operators end up using that. We've also got Magnum, Designate, Minasco alarm and Cinder encrypted volume. So there's a lot of new resources coming in. Traditionally, we have put resources that were from non-integrated projects into our contract directory and not officially released them. So if we just go on to the next slide, we've just got a summary of big tense changes. So now as we've de-emphasized the meaning of integrated projects, HEAT has to decide how to deal with a wide variety of OpenStack ecosystem projects implementing HEAT resources. So traditionally, Contrib was for resources that were from non-integrated projects and also resources that required admin functionality. In Liberty, the Contrib directory is deprecated. All of those resources that are of an appropriate quality have been brought into the HEAT tree. So if you install HEAT, you have all of these resources. Other big tense changes, the functional integration tests have a migrating out of tempest and are moving into the HEAT tree. This has been quite good because it's raised the profile of functional integration and integration testing and we're getting a lot more participation from developers in writing those tests. So we've built quite a large suite in a fairly short amount of time. And just recently the template guide, otherwise known as the hot guide, has moved from the OpenStack user guide into the HEAT developer documentation namespace. Again, this should result in more participation from HEAT developers in writing documentation and recipe-style content. So going on to some more Liberty-planned features. Now this is sort of related to the new resources. Now that we have a significant number of new resources coming into tree, we need to do a better job of indicating to the user what resources are available to them when they're launching their stacks. So we'll be doing more resource availability based on user roles and service catalog. What this means is that we have a better ability of giving feedback at the validation stage of the stack launching process that a user can or cannot use a particular resource type based on whether the endpoint is available. But previously it would still fail but it would fail quite late in the process because it would only fail when that resource is being created. So it'll result in a failed stack. But now we're bringing it towards the front of the process so you'll get a validation error before the stack even launches. So going on to the next Liberty-planned features. So Convergence, it's a fairly large effort that we've been working on for a couple of cycles to rewrite a portion of the core heat engine to essentially break down the orchestration into resource level operations instead of stack level operations. It has a number of advantages. It sort of removes the concept of a stack lock so you can have multiple stack operations in flight at the same time. It means that operations happen at a resource level so that each individual resource level operation is spread out over a different heat engine and it's all coordinated over Oslo messaging and depends on a consistent database at the back end to make sure that the entire stack isn't a consistent stack. So we're going to have to make a call at some point in the Liberty cycle whether we enable this feature for the Liberty release. I think conservatively speaking it's not going to be enabled by default. It's being developed. It's maturing entry so we have quite good momentum and we're getting some progress on getting the whole integration and functional test suite working when convergence is enabled but I think conservatively speaking it's likely to remain switched off for the Liberty release but there may be scenarios where operators would want to enable it just to try it out and see if it works on their use cases. So that's progressing quite well and it's hard to say at this point how really it's going to be for the Liberty release. So going on to the next Liberty plan features there'll be a selection of new template intrinsic functions to help with transformation from one arbitrary data structure to another. Lists to dicks, strings to everything. There may be a new YACL based intrinsic function which will let YACL as the yet another query language library that's come out of the Murano and Mistral projects, I believe. We have a proof of concept for that so we're not quite sure how that will pan out but it's something we'll evaluate and being able to specify YACL expressions within each template could give some quite nice expressability in composing templates. And finally on to the secar slide. So there's been a real push to adopt the car across a number of OpenStat projects and we say this is a good thing and it looks like it's definitely the right time for this to happen. So one area where this will be happening in the Liberty cycle is using the car for the software configuration transport. What this means is that no other servers that are brought up need to talk to heat to fetch the configuration data that's required to do whatever subsequent software configuration whether that be shell scripts or puppet manifests or whatever software countercook they have on their servers. So our current transports are either talking directly to heat or fetching from a Swift temp URL. Ideally what we need is a proper messaging platform because this is a perfect scenario for messaging. So in heat we will support the car as an option for these transports. So no other servers will fetch configuration data from the car queue and when it needs to signal heat it will just push the message into a different car queue and that will be eventually fetched by heat to allow the software configuration to be driven by messaging. And there's other areas where heat would benefit from the car integration. It's too early to say at this point whether this will happen for Liberty but use notifications is something that's strongly desired. Just a mechanism for telling users about things that are happening in their stack but which don't justify halting the stack and just returning an error. Things like notification of use of deprecated resources, notification of events. We currently have an event API in heat but it would be a much better implementation if it was driven by as a car style message queue. But a lot of other open stack projects would benefit from this kind of user event notification as well. So there's a push to make it a cross-project spec rather than a heat-specific thing. So we'll see how that progresses. There might be something that emerges in Liberty or it might take an extra cycle to work it out in a way which benefits all projects. So that's it. If you want to contact me you can email me sbakeratredhat.com. I'm Steve Baker on FreeNode and you're most welcome to come into the heat channel on the FreeNode network if you have any questions about heat. And thanks very much. That's it.