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.
Keystone and many current OpenStack API components run in an Eventlet based http server. Eventlet is designed to perform well in networked environments and handles everything in a single thread.
The developers responsible for the Keystone project have recently recommended using Apache (with the mod_wsgi module) as a front-end rather than the traditional “Keystone” Eventlet-based process.
By using Apache as the front-end for Keystone, one gains better performance due to Apache’s ability to do multithreading. One can also take advantage of the variety of http server modules currently available for Apache. One popular module, Shibboleth, provides the ability to use one set of credentials to authenticate against multiple OpenStack clouds (more info here).
Here is a straight forward guide on how to setup Keystone to utilize Apache in your existing OpenStack deployment.
If you already have an existing Swift cluster and you would like to add additional storage, you can use the swift-ring-builder command on the ring builder files from any server that you have the utility installed on. Once you update the files, you will need to push them out to all the nodes in your cluster.
TLS and SSL are two critical technologies which underly much of the secure communications that occur on the internet. Over the past few years, spurred by increasingly effective attacks and a desire for new functionality, SSL and TLS have seen many new features, as well as practical improvements.
Python is currently in a transitional period between Python 2 and Python 3. For
the past few years, all new feature development has been happening on Python 3,
including new features in Python’s
ssl module. This means that Python 3 users
have had acccess to these improvements to TLS, but Python 2 users (still the
majority of Python users) have been falling behind.
As you may already know, Rackspace just launched OnMetal, which is built with OpenStack Ironic and ironic-python-agent (IPA). I want to highlight the code, what our control plane looks like, and how we operate it. My hope is that this post can help others test and deploy Ironic with IPA.
With the recent announcement of Cloud Images, creating custom images for the Rackspace Public Cloud is now a functionality users have at their disposal.
To simplify the custom image creation process, Rackspace released boot.rackspace.com, a collection of iPXE scripts that allows you to rapidly network boot Operating Systems, Utilities and other tools very easily. It’s especially useful for remote access environments when you don’t want to utilize remote attached CD’s in a Dell DRAC, HP iLO or some other type of remote tool. It’s especially awesome for bootstrapping your own custom installation on a Cloud Server!
In the world of Cloud Computing, hypervisors and disk image formats come in various shapes & sizes and are by no means made equal. In the Rackspace Public Cloud, we utilize Citrix XenServer as our hypervisor, which requires that our disk images be in the VHD format.
One of our highest priorities at Mist.io is to never break production. Our users depend on it to manage and monitor their servers and we depend on them. At the same time, we need to move fast with development and deliver updates as soon as possible. We want to be able to easily deploy several times per day.
When we, at Rackspace were working on a data visualization dashboard which uses AngularJS framework, we needed to abort requests. Fortunately, AngularJS has amazing built in services of which $http and $resource helped us make these XHR(Ajax) requests much simpler. There are many resources to figure out which might be better for your use case. I’m going to describe how I implemented aborts in $resource and $http in an unified way which increased the performance and showed correct data.