OpenStack Heat and DevStack on HP Cloud

Openstack is clearly making waves and rapidly becoming the de-facto standard in private clouds.
In the last few releases, its orchestration engine, Heat, which was originally inspired by Amazon CloudFormation, is getting more mature with more desired functionality.
I wanted to share my experience with setting up my own Heat playground as the orchestration service of a Devstack deployment running inside an HP Public Cloud VM.

Cloudify natively integrates with OpenStack. Try it out.  Go

I started by launching* a standard large size VM running Ubuntu 12.04 (actually I tried first with 14.04 and saw a few issues which drove me back to 12.04) on HP Cloud (obviously it can be run on any cloud environment).
*The default fixed subnet for devstack is 10.0.0. I recommend attaching the VM mentioned above to a different subnet range (although you can configure devstack to a different fixed subnet too).
Once the VM was ready, I SSHed into it and installed git:

I then cloned the devstack git repo to the homedir of my VM:

and cd into the Devstack folder that was just created:

Examining the stackrc file, I saw that although the Neutron service was installed, the default enabled service was actually the Nova network (n-net).
In order to have the more modern and feature-rich Neutron, I disabled the Nova network n-net  and enabled the Neutron services (q-svc, q-agt, q-dhcp, q-l3, neutron) in the local.conf configuration file (you will need to create this under the Devstack folder). I took this opportunity to also set the admin passwords in the local.conf file:

The next step is to actually go through the Devstack installation process:

These scripts take care of installing, configuring and running the Devstack deployment. With the local.conf file we created. The installation can actually run unattended (which is great because it takes more than 10 minutes to complete, a great opportunity for a coffee break or going through emails…)
Once the script finishes the installation process, Devstack is running and has a screen associated with it so that you can attach and detach it to see what is going on:

To switch between the different service windows type Ctrl-A “.
Ctrl-A Ctrl-D will detach from it leaving Devstack running.
By default, VMs launched inside DevStack running on a VM host will not have Internet access.
To allow Internet, we will need to enable IP forwarding and NATing on the host machine:

You can access Horizon, its web UI, by typing http://<Your VM public/floating IP>/
The admin user is admin and the password is what we set in the local.conf.
Under Project you will see the orchestration service.
Now that our playground is ready, lets start playing with Heat…
Defining an orchestration (stack) in Heat is done by defining a HOT template (Heat is also compatible with CloudFormation syntax, but I will not go into that).
Templates can be defined in YAML or JSON. I find YAML much easier to read so I will stick with it for my examples.
I started with a basic stack example from the Openstack git repo: https://github.com/openstack/heat-templates/blob/master/hot/F18/WordPress_Native.yaml
This stack template simply provisions a VM, installs the WordPress services (Apache, MySQL and the WordPress web app) and configures it.
There are input parameters such as the user/password and output parameters such as the application URL.
Click the project->Orchestration ->stacks and then Launch Stack.
You can use the actual git URL to create the stack.
The “Environment Source” can be used to initialize the parameters defined in the stack template.
If we leave it empty, Heat will ask us to fill in the parameters in the next dialog box.
After clicking Next, we name the stack and fill in any parameters that were not initialized, and then we can launch the stack.
There are four views to track the deployment status of the stack.:

1. Topology view that shows the stack resources and their relationships in graph format.
2. Overview that just gives the basic properties of the stack.
3. Resources view that lists all of the resources that were deployed.
4. Events log that shows us the progress of the stack’s deployment.
5. This was neat, in a few clicks we launched a ready to use WordPress server.

However, in real life deployments, things can get a bit more complicated, so let’s add some typical deployment customizations into the mix:

1. Let’s separate the MySQL and the Apache from each other.
2. Let’s build separate networks for the application data and the application’s public access.

These customizations make things more interesting on the Heat side. We need to define additional networks resources such as networks, subnets router and ports.
In addition, we need to create dependencies between the network resources and the VMs.
For example, we need the network provisioned before we can launch the VMs.
We also need a dependency between the Apache VM and the MySQL VM. We then also need to inject the MySQL IP address to the WordPress configuration on the Apache VM.
The dependency graph goes as follows:
First we define the networks and the router. Then we define the subnets, tying them to the networks by the “network_id: { get_resource: network_id/name}.
At the same time we can define the router_gateway tying it to the router “router_id: { get_resource: router }” and the pre-existing public network.
After the networks and the router are defined, we can define the router interface that does the same get_resource to reference both elements.
In parallel, the port, which depends on the network and the subnet, is defined too.

Lastly, the two servers and the floating IP are defined. The floating IP is dependent on the definition of the server port.

The MySQL server VM is dependent on its server data port and a random app network port for outbound Internet access.
The Apache server VM is dependent on its server app port as well as the floating IP, and a random data network port for accessing the MySQL on a separate network.
The template is available at http://s3.amazonaws.com/yoramw/wordpress.yaml
Here is the topology graph that was created when we launched our more sophisticated stack:

The network diagram view:

Feel free to let me know in the comments how this tutorial worked out for you.