Head in the Clouds

If you didn't see the news last week from Cloud Expo, Zenoss announced the release of a monitoring package for CloudStack. The initial version permits a cascading view of a CloudStack, and measuring a number of performance issues over time. There are plenty of future plans as well, including the monitoring of the CloudStack management server and performance for a number of additional items including speed of deployment and other factors.

Kudos to Zenossian Chet Luther for pushing out this awesome work.

Want to know more?

Check out Zenoss at http://community.Zenoss.org

CloudBridge is a free, open-source, downloadable add-on to CloudStack that translates Amazon EC2 API calls to native CloudStack API calls so that clients can continue using existing EC2-compatible tools with CloudStack.

CloudBridge 1.0.2 contains a significant refactoring of much of the internal code as well as improvements to the overal architecture. As a result of these changes, every supported command in CloudBridge has been refactored and in many cases actually work now.

Beyond just the code, the documentation has been improved and made more accessible.

You can find the installation package here:
http://sourceforge.net/projects/cloudstack/files/CloudBridge/

You can find the latest revision of the documentation here:
http://docs.cloud.com/CloudBridge_Documentation

Please let us know if you have any questions or problems using this release candidate for 1.0.2 by communicating on the cloudstack-devel mailing list, or filing bugs at http://bugs.cloud.com

There are situations, such as training environment, in which it's desirable to run CloudStack in a virtualized environment. If you read the official documentation you'll see that you must have hypervisor hosts with hardware virtualization. However there are some nifty workarounds that you can use to setup a CloudStack environment all within a virtualized environment, such as your laptop. Obviously you wouldn't want to run it in production this way, but there are a number of realistic use cases where it makes sense.

I should note up front, that this doesn't work with all hypervisors, some of which only work with hardware virtualization, however it does at least work for XenServer. Also, you won't be able to install any OS as a virtual machine, you'll essentially be limited to Linux distros that support Xen paravirtualization, which thankfully is most of them.

You of course provision a virtual machine to act as your management server, database, secondary and primary storage. But then also provision additional virtual machines to act as XenServer hosts. Once you've installed all your virtual machines, but before you attempt to add the first hypervisor to your CloudStack environment, you'll need to login to your database and run the following commands:

This week we are attending PuppetConf, an operation conference put on by PuppetLabs in Porland, Oregon, There are descriptions of the tracks below but if you can't be here for the event they are going to be streamed live. "Tickets" to the online streaming are free and you can register to view them through EventBrite.

The PuppetLabs team has graciously included David Nalley and I as part of the program but there are a ton of great presenters attending for the following tracks if you can't make it to Portland, I highly recommend you tune in remotely. Here's a taste of the program:

Cloud Computing

Industry leaders from Facebook, Citrix, Eucalyptus, Cloud.com, Cloudera, Redhat, and jclouds guide you through the benefits of various cloud infrastructures and PaaS services, setting up a public or private cloud environment, and a "how-to" for managing large EC2 infrastructures with Puppet. At lunch, a panel session moderated by GigaOM analyst and blogger Derrick Harris will provide an insightful look to the future of cloud computing.

DevOps

DevOps has been described as a new practice, the codification of how smart people have always run IT, a buzz word, and a meme that has jumped the shark. One thing is clear: the term incites discussion wherever it goes. We intend PuppetConf to be no different and have gathered some of the DevOps luminaries to present. This includes John Willis and Damen Edwards, hosts of the DevOps Cafe podcast, and John Vincent, avid blogger, developer of Noah and Director of Operations at Vertical Acuity. Bringing the Dev side to the table are: Deepak Giridharagopal, Principal Engineer for Dell, and Kit Plummer, Chief Solutions Architect for MaestroDev.

Puppet 201

For those of you who are already experienced Puppet users, we offer a track addressing advanced topics. The track covers integrating with other tools, building your own Puppet subcommands with the Faces API, and talks aimed at bringing you up to speed with using and developing MCollective for orchestration. Advanced users from Google, Media Temple, and eBay will be dishing out expert advice on extending Puppet to fit a customized infrastructure.

Puppet 101

We will be presenting a range of introductory level talks aimed at getting you started with Puppet. Early adopter of Puppet, Digant Kasundra, will be presenting on Puppet best practices and will share his years of experience managing an infrastructure at Stanford. Martin Englund of VMWare plans to outline the steps it takes to transition Puppet into a large enterprise, taking you from building a proof of concept to working with Puppet Labs.

A number of questions have been posed to me of late and brought me to the realization that CloudStacks repo structure is poorly documented, so this is at least an attempt at a CloudStack git repo disambiguation page.

CloudStack maintains a number of branches in the git repo, the most interesting of these are master and 2.2.y. All of the future 2.2 releases have their start from the 2.2.y branch. For larger features, development and testing will be branched off of the 2.2.y branch. In example, the 2.2.y-clvm branch is 2.2.y with the Clustered LVM feature added. Once that feature is tested and ready to go it can be merged back in to 2.2.y.

Master, which is where Acton (v3.0) is currently being developed, is a bit more cutting edge.

How does all of this move from a rather generic branch to what we actually produce a release from? Well, when a release hits code freeze, another version-specific branch is typically created. In example, 2.2.12 has a targeted code freeze of 9/14/2011, and if all goes according to schedule the 2.2.12 branch will be created from 2.2.y on that date. This allows development on the 2.2.y branch to continue to progress, while hopefully stabilizing 2.2.12 and letting the focus on that branch be about solving those version specific bugs.

Finally, when a version specific branch is declared 'gold' and ready for release, the release engineering team will tag the release with the version number. To ensure there are no conflicts with the version specific branches, the tag will have tag- prepended. So when 2.2.12 is tagged for release it will be tag-2.2.12. All of the releases are built from the versioned tag.