OpenStack Heat plugin for Apache CloudStack

This blog post presents a plugin for OpenStack Heat which adds support for Apache CloudStack resources and thus enables a template-based orchestration on CloudStack using Heat. As this plugin extends the standard Heat’s resource type list it can also be used within our Hurtle orchestrator for providing your application as a service or any other application underlying on Heat. This work follows from our earlier work in which we developed a Heat plugin for SDC.

An orchestration is a crucial part of a cloud application and service delivery. OpenStack Heat lets users to specify templates describing application resources such as virtual machines, networks, security groups, … including their dependencies. Based on these templates Heat then does the job of resolving these dependencies and decides the order in which the resources are being created and creates them. A heat plugin extends the set of the available resources and these are then handle in the same way as the original ones.

While Heat has become popular OpenStack component and usually is the first-choice orchestrator for the most of OpenStack users and administrators, CloudStack lacks a dedicated orchestration solution and generally depends on third-party solutions such as Cloudify. With Hurtle in mind we developed a plugin that extends the set of available Heat resources with CloudStack ones thus opening the CloudStack universe to Heat users. Moreover, now you can “” in CloudStack environments as easy as in OpenStack.

Developing a heat plugin requires a resource specification including a specification of the resource attributes, specification of how to handle the standard resource operations such as resource creation, deletion and providing a mechanism that checks whether the operation succeeds. More information on how to write an Heat plugin can be found in our presentation here.

So far our plugin integrates following CloudStack resources:

  • Cloudstack::Compute::VirtualMachine (basic & advanced zone) – resource representing CloudStack virtual machine.
  • Cloudstack::Network::SecurityGroup (basic zone) – resource representing security group resource including definition of security group’s firewall rules.
  • Cloudstack::Network::VPC (advanced zone) – resource representing CloudStack Virtual Private Cloud (VPC).
  • Cloudstack::Network::Network (advanced zone) – resource representing CloudStack Network.
  • Cloudstack::Network::StaticNAT (advanced zone) – resource representing static NAT between a VM (::VirtualMachine) and a public ip address (::Address).
  • Cloudstack::Network::Address (advanced zone) – public IP address resource associated to a VPC.

In order to be able to use this plugin you need access to a running Heat service and access to a CloudStack API (endpoint, API key, secret key). If needed, Heat can be installed in a VM using Packstack as described in documentation for the ICCLab’s Heat plugin for SDC (up to step 4). Further steps how to integrate the CloudStack plugin to the Heat engine can be found at project’s github repository.

Screenshot 2015-11-25 09.58.11

[Resource types available in our “CloudStack region”]

This is work in progress and more resources will follow soon and pull requests are always welcome. Nevertheless, the current resource stack provides operational environment for orchestrating many different workloads. As an example we demonstrate the plugin’s capability of orchestrating open source IP Multimedia Subsystem (IMS) solution – Project Clearwater as one of ETSI’s NFV use cases.

This work was made possible by the KTI ACEN project in collaboration with Citrix.

Leave a Reply

Your email address will not be published. Required fields are marked *