Over the last year, Angus Salkeld and I have been developing a IAAS high availability service called Pacemaker Cloud. We learned that the problem we were really solving was orchestration. Another dev group was also looking at this problem inside Red Hat from the launching side. We decided to take two weeks off from our existing work and see if we could join together to create a proof of concept implementation from scratch of AWS CloudFormation for OpenStack. The result of that work was a proof of concept project which provided launching of a WordPress template, as had been done in our previous project.
The developers decided to take another couple weeks to determine if we could get a more functional system that would handle composite virtual machines. Today, we released that version, our second iteration of the Heat API. Since we have many more developers, and a project that exceeded our previous functionality of Pacemaker Cloud, the Heat Development Community has decided to cease work on our previous orchestration projects and focus our efforts on Heat.
A bit about Heat: The Heat API implements the AWS Cloud Formations API. This API provides a rest interface for creating composite VMs called Stacks from template files. The goal of the software is to be able to accurately launch AWS CloudFormation Stacks on OpenStack. We will also enable good quality high availability based upon the technologies we created in Pacemaker Cloud including escalation.
Given that C was a poor choice of implementation language for making REST based cloud services, Heat is implemented in Python which is fantastic for REST services. The Heat API also follows OpenStack design principles. Our initial design after our POC shows the basics of our architecture and our quickstart guide can be used with our second iteration release.
A mailing list is available for developer and user discussion. We track milestones and issues using github’s issue tracker. Things are moving fast – come join our project on github or chat with the devs on #heat on freenode!
I am super pleased to announce the release of Pacemaker Cloud 0.6.0.
Pádraig Brady will be providing a live demonstration of Pacemaker Cloud integrated with OpenStack at FOSDEM.
What is pacemaker cloud?
Pacemaker Cloud is a high scale high availability system for virtual machine and cloud environments. Pacemaker Cloud uses the techniques of fault detection, fault isolation, recovery and notification to provide a full high availability solution tailored to cloud environments.
Pacemaker Cloud combines multiple virtual machines (called assemblies) into one application group (called a deployable). The deployable is then managed to maintain an active and running state in in the face of failures. Recovery escalation is used to recover from repetitive failures and drive the deployable to a known good working state.
New in this release:
- OpenStack integration
- Division of supported infrastructures into separate packaging
- Ubuntu assembly support
- WordPress vm + MySql deployable demonstration
- Significantly more readable event notification output
- Add ssh keys to generated assemblies
- Recovery escalation
- Bug fixes
- Performance enhancements
Where to get the software:
The software is available for download on the project’s website.
Recently Angus Salkeld and I have decided to start working on a second approach to Pacemaker Cloud monitoring. Today we monitor with Matahari. We would also like the ability to monitor with OpenSSH’s sshd. With this model, sshd becomes a second monitoring agent in addition to Matahari. Since sshd is everywhere, and everyone is comfortable with the SSH security model, we believe this makes a superb alternative monitoring solution.
To help kick that work off, I’ve started a new branch in our git repository where this code will be located called topic-ssh.
To summarize the work, we are taking the dped binary and making a second libssh2 specific binary based on the work of the dped. We will also integrate directly with libdeltacloud as part of this work. The output of this topic will be the major work in the 0.7.0 release.
We looked at python as the language for dped, but testing showed that not to be particularly feasible without drastically complicating our operating model. With our model of running thousands of dpe processes on one system, one dpe per deployable, we would need python to have a small footprint. Testing showed that python consumes 15 times as much memory per dpe instance vs a comparable C binary.
We think there are many opportunities for people without a strong C skillset, but with a strong python skillset to contribute tremendously to the project in the CPE component. We plan to rework the CPE process into a python implementation.
If you want to get involved in the project today, working on the CPE C++ to python rework would be a great place to start!