1. Workload LCM with Heat Florin Stingaciu System Architect Lance Haig
featuring
Florin Stingaciu
System Architect
Lance Haig
SOLUTION Architect
&
As the Openstack community continues to simplify the cloud deployment process, more and more businesses are adopting Openstack within their infrastructure. However, there seems to be a lack of knowledge base in the community regarding workload onboarding and management using tools native to Openstack.
This talk introduces the advanced use of Heat (with a particular focus on SoftwareDeployment resources) in order to provide a structured process for deploying and managing workloads in the cloud.
At the core of this structured process is a base repository containing basic building blocks for Openstack infrastructure, as well as a structure (with examples) for developing and deploying software configurations at all phases of an instance’s lifecycle.
The target audience for this talk is the cloud end-user who has some familiarity with Heat (or other similar cloud orchestration tools), as well as devops teams managing cloud resources on behalf of cloud non-friendly users.

2. Agenda Workloads & Openstack Deployment Options
Software Deployments Overview
Framework for working with Heat and Software Deployments
Reverse Proxy Demo
Kubernetes w/ Kargo Demo
Wrap-up

3. What is a workload?
A collection of resources that work together in order to offer/produce a particular service/output.
Logical components that make up a workload
Software Configuration Deployment
Software Configuration LCM
Infrastructure Deployment
Infrastructure LCM

4. Openstack Workload Deployment Options All Manual Deployment
User deploys each infrastructure resource manually
User configures each software component manually
Disadvantages
Slow and error prone process
Is not easily reusable
No LCM
No easy way to group all infrastructure resources that belong together
Although quite trivial, this method of deployment is still very popular

5. Openstack Workload Deployment Options Infrastructure with Heat / Manual Software Configuration
User automates infrastructure deployment with Heat via Heat templates
User configures each software component manually
Advantages:
The Heat template now serves as a “recipe” for the infrastructure deployment
Heat can be leveraged to determine all resources involved in this workload as well as their current status
Infrastructure LCM can be performed via Heat (scaling/adding new resources)
Disadvantage
A redeployment/scaling action will still require manual software configuration
No software configuration LCM

6. Openstack Workload Deployment Options Infrastructure with Heat / Software Configuration via Cloud-Init
User automates infrastructure deployment with Heat via Heat templates
User leverages cloud-init to automated software configuration at instance startup
Advantages:
The Heat template now serves as a “recipe” for the infrastructure deployment
Heat can be leveraged to determine all resources involved in this workload as well as their current status
Infrastructure LCM can be performed via Heat (scaling/adding new resources)
A redeployment is one-click away
Disadvantage
No software configuration LCM (updating the cloud-init in any resource will lead to a resource recreate (destroy & create) action)

7. Openstack Workload Deployment Options Infrastructure with Heat / Software Configuration via Cloud-Init and CM tool
User automates infrastructure deployment with Heat via Heat templates
User leverages cloud-init to automate software configuration at instance startup to install required CM tool/agents
User leverages CM engine to deploy software configuration
Advantages:
The Heat template now serves as a “recipe” for the infrastructure deployment
Heat can be leveraged to determine all resources involved in this workload as well as their current status
Infrastructure LCM can be performed via Heat (scaling/adding new resources)
A redeployment is one-click away
Software LCM
Disadvantage
Two different systems to control the LCM of a workload

8. Openstack Workload Deployment Options Infrastructure with Heat / Software Configuration via Heat Software Deployments
User automates infrastructure deployment with Heat via Heat templates
User leverages Heat software deployments to deploy and manage software configurations
Advantages:
The Heat template now serves as a “recipe” for the infrastructure deployment
Heat can be leveraged to determine all resources involved in this workload as well as their current status
Infrastructure LCM can be performed via Heat (scaling/adding new resources)
A redeployment is one-click away
Software LCM
Single point of control

9. What are Software Deployments?
A SoftwareDeployment is a type of resource in Heat that applies a Heat SoftwareConfig resource to a particular instance
Software Deployments require a number of agents to be available at run time. These agents can be made available by:
Installing them at instance boot time via cloud-init
Pre-packaging them in the image
Agents running on the instance continuously poll Heat for new or updated SoftwareDeployment resources and apply them when available
In short, Heat provides us with a native configuration management engine that lets the user apply software configurations by declaring software deployment resources

10. Software Deployments Format
Simple webserver example
The SoftwareConfig resource encapsulates the configuration required to install the webserver
The SoftwareDeployment resource associates the SoftwareConfig resource to an instance
The Signal Transport indicates the method in which the agents should signal the status of the software deployment
Actions represent at what resource status (create, update, suspend and delete) this software deployment should be applied
http_config:
type: OS::Heat::SoftwareConfig
properties:
group: script
config: |
#!/bin/bash
yum -y install httpd
echo "Hello World!" > /var/www/html/index.html
service httpd start
http_deployment:
type: OS::Heat::SoftwareDeployment
config: { get_resource: http_config }
server: { get_resource: instance }
signal_transport: HEAT_SIGNAL
actions:
- CREATE
- UPDATE

11. Supported hooks
Group attribute in the SoftwareConfig represents what type of hook this software configuration requires
Many types of hooks are available currently
Quite simple to develop new hook for any type software configuration
ansible
apply-config
cfn-init
docker-cmd
docker-compose
hiera
json-file
kubblet
puppet
salt
script

12. Software Deployment Flow
os-collect-config on the instance will use the software_config_trasport attribute of the instance to poll Heat for software deployments
os-refresh-config will trigger heat-config
heat-config will determine the appropriate hook to execute the software configuration
heat-config-notify will use a signal_transport attribute of the software deployment to deliver the status of the deployment (including outputs) back to Heat
Cloud-init versus Software Deployments
You can only apply software configs using cloud-init at instance creation
Creating dependecies between instances at a software configuration layer with cloud-init is a HUGE hassle
There is no way to pass back information to Heat when using cloud-init. Software deployments support Outputs

13. Putting it all together
Workloads are highly flexible systems that can be deployed and managed in many different ways
However, a structured framework can be developed for the standardization of each workload workflow components
This framework should
Encourage collaboration as most workload components are quite modular in nature (ie. an Openstack network definition, a webserver installation)
Leverage version control as a means to record workload changes over time
Minimize the amount of different systems involved to improve ease of use

14. The Framework Base Git Repository
/lib - This directory contains Heat templates for two things:
Basic building blocks for Openstack Infrastructure
Networks
Instances
Volumes
Clusters
Load-Balancers
Basic building blocks for various software configurations (ie. install web server, add user, disable selinux)
Ubuntu
RHEL
Boot Config scripts to install required agents for software deployments

15. The Framework Base Git Repository
/env - Heat environment files corresponding to different operating systems that contain all the resources created in the lib directory (local file paths only)
/env-ext - This directory is the exact same as /env however each environment file uses URLs to point to the components hosted on gitHub; this means that anyone who wants to use this library would just have to download these files without having to download the whole repo
/tests - This directory contains a number of Heat templates that utilize the components in the lib directory to test their functionality (also serve as good examples)
Openstack infrastructure tests
Software Configuration tests
/README.rst - A good overview of the overall repository and workflows for developing new components

16. Reverse Proxy Demo Network Stack Definition
type: HeatLib::Network::FullStack
properties:
name: { get_param: name }
cidr: { get_param: network_cidr }
external_network: { get_param: external_network }
Parameters:
name: reverse_proxy cidr: /24 external_network: public_network

17. Reverse Proxy Demo Security Group Definition
instance_access:
type: HeatLib::SecurityGroups::Generic
properties:
name: { get_param: name }
ports: { get_param: ports }
protocols: { get_param: protocols }
Parameters:
name: reverse_proxy ports: 22,80,443 protocols: tcp

18. Reverse Proxy Demo Instance Definition
type: HeatLib::Instance::Basic
properties:
name: { get_param: name }
key: { get_param: key }
image: { get_param: image }
flavor: { get_param: flavor }
subnets:
- { get_attr: [ network_stack, subnet_uuid ] }
security_groups:
- { get_attr: [ instance_access, security_group_uuid ] }
Parameters:
name: reverse_proxy key: my_key image: centos flavor: m1.small

19. Reverse Proxy Demo Floating IP Definition
type: HeatLib::Network::FloatingIP
properties:
external_network: { get_param: external_network }
port: { get_attr: [instance, instance_addresses, {
get_attr: [ network_stack, network_uuid ] }
, 0, port ] }
Parameters:
external_network: public_network

20. Reverse Proxy Demo Volume Definition
data_volume:
type: HeatLib::Volume::Basic
properties:
name: { get_param: name }
size: { get_param: volume_size }
instance: { get_attr: [ instance, instance_uuid ] }
Parameters:
name: reverse_proxy size: 10

21. Reverse Proxy Demo Software Deployment - Volume Mount Definition
data_volume_mount:
type: HeatLib::SoftwareConfig::VolumeMount
properties:
mount_path: "/data/"
make_fs: "true"
volume_id: { get_attr: [ data_volume, volume_uuid ] }
instance: { get_attr: [ instance, instance_uuid ] }
Parameters:
N/A

22. Reverse Proxy Demo Software Deployment - Webserver Definition
type: HeatLib::SoftwareConfig::HTTP
properties:
instance: { get_attr: [ instance, instance_uuid ] }
Parameters:
N/A

23. Reverse Proxy Demo Software Deployment - Reverse Proxy Definition
reverse_proxy_google:
type: HeatLib::SoftwareConfig::
depends_on: webserver
properties:
instance: { get_attr: [ instance, instance_uuid ] }
proxy_pass: "/google
Parameters:
N/A

24. Reverse Proxy - Demo Video

25. Kubernetes with Kargo - Demo Video

26. Summary
Heat can be leveraged to provide both infrastructure and software configuration life cycle management
These Heat capabilities must be combined with a framework that consists of
A repository serving as the base for this framework that allows for:
Collaboration
Version Control
Workload Deployment Workflow
Workload Update Workflow
This framework enables the cloud end-user to minimize time spent on cloud administrative actions and spend more time on workload development

27. Links GitHub Organization: https://github.com/heat-extras
Heat Lib:
Heat Tutorial:
Part 1-3: Heat Basics
Part 4: Cloud-init
Part 5: Software Deployments
Part 6: Vertical and Horizontal Scaling
More to come

28. Thanks for joining us! P.S. We’re hiring!
Q/A
Thanks for joining us! P.S. We’re hiring!