If you are an OpenStack contributor, you likely rely on DevStack for most of your work. DevStack is, and has been for a long time, the de-facto platform that contributors use for development, testing, and reviews. In this article, I want to introduce you to a project I’m a contributor to, called openstack-ansible. For the last few months, I have been using this project as an alternative to DevStack for OpenStack upstream development, and the experience has been very positive.
Federation support in OpenStack has been greatly improved in the Kilo release, and, while there are still some rough edges, the feature is now usable, if you don’t mind adding a little elbow grease. This article focuses on one specific configuration called Keystone-to-Keystone federation (or K2K), in which users of an OpenStack cloud use their credentials to access services in another OpenStack cloud, with both clouds using Keystone as their identity services.
This is the fourth and last article in my series on OpenStack orchestration with Heat. In the previous articles, I gave you a gentle introduction to Heat, and then I showed you some techniques to orchestrate the deployment of single and multiple instance applications on the cloud, all done with generic and reusable components.
Today I’m going to discuss how Heat can help with one of the most important topics in cloud computing: scalability. Like in my previous articles, I’m going to give you actual examples that you can play with on your OpenStack cloud, so make sure you have an environment where you can run tests, whether it’s a Rackspace Private Cloud, DevStack or any other OpenStack distribution that includes Heat.
This is the third article in my series on OpenStack orchestration with Heat. In Part 1, I introduced the HOT template syntax, and then in Part 2, I showed you some of the techniques Heat offers to orchestrate the deployment of applications that run entirely within a single compute instance.
Today, building on the same ideas exposed in my previous article, I’m going to show you how to design deployments across more than one instance, and I’m going to demonstrate these concepts by deploying an application that runs on a server and connects to a MySQL database on another server. You have seen how to deploy a Python application in my previous examples, so, to add some variety, I’m now going to switch to a PHP application as guinea pig. That application is none other than the venerable Wordpress.
Welcome to the second part of my series on OpenStack orchestration with Heat. In the previous article, I gave you an introduction to Heat orchestration. All the examples that I showed you were simple and not terribly useful, as they were only intended to introduce the structure of the HOT (Heat Orchestration Template) syntax.
In today’s article, I’m going to elevate the complexity quite a bit, demonstrating some of the tricks you can use with Heat to perform deployments of single instance applications. As with the introductory examples, you are encouraged to try my examples on a Rackspace Private Cloud, DevStack or any other OpenStack installation that includes Heat.
With this article I begin a series of hands-on developer oriented blog posts that explore OpenStack orchestration using Heat.
To make the most of this article, I recommend that you have an OpenStack installation where you can run the examples I present below. You can use our Rackspace Private Cloud distribution, DevStack, or any other OpenStack distribution that includes Heat.