Upgrading CloudStack from 4.0.0-incubating to 4.0.1-incubating

I spent my weekend upgrading my cloud. Yes my CloudStack IaaS cloud isn’t going to threaten AWS EC2  anytime soon, but it still serves a vital purpose for me, giving me a place to provision services, provide a test bed, and many other things.

What does my personal cloud look like? It’s a small cloud of 6 physical nodes (Dell R210s) based in a datacenter somewhere in San Jose. One of the 6 nodes is a CloudStack management server running CentOS 6.3 and KVM running on the same node, and three more KVM nodes. I also have one XenServer and one XCP node.  That said, the principles behind upgrading remained the same regardless of the machine.

So why did I upgrade? Well Apache CloudStack 4.0.1-incubating, was announced today (and released late last week) What’s the difference between 4.0.0-incubating and 4.0.1-incubating? Well, there are no new features, but there are a number of bugfixes included.

CloudStack versions now adhere to Semantic Versioning, which means this is merely a maintenance update or a bugfix update. Bugfix releases are great for production deployments – the change is minimal, and it’s all focused on fixing problems. Within open source projects though, bugfix releases tend to be unsexy. Many communities skip them entirely because developers want to work on new things and don’t work on keeping up with the massive investment that is backport fixes. It is, I think, a reflection of project maturity and operator-driven community of CloudStack that a bugfix release is already out and another is on the way (4.0.2 planning emails started flowing even before 4.0.1 was announced.) Yes many developers are looking at the next feature release (4.1.0) and even the one past that (4.2.0) but that doesn’t diminish the importance of the 4.0.x install base, or the expectations that those folks have – many folks, especially large cloud deployments aren’t going to want to perform a feature upgrade every few months, but can tolerate the smaller bugfix releases.

But enough about that – if you have 4.0.0 deployed you are interested in how the upgrade went aren’t you? So I have confession to make. First, I didn’t completely follow the upgrade directions. You should. The management server upgrade was painless – I ran:

# yum -y update cloud-*

followed by

# service cloud-management restart

And all was well.

Next was my KVM agents. I shelled into these as well (yes, I know, I am awful for not leveraging configuration management, especially when I am such a CM advocate), but my environment is where I test installation instructions, and most (but not all) of the upgrade instructions) I didn’t bother to stop the agents, or even to put them into maintenance mode. I ran

# yum -y update

to get all of the operating system upgrades as well as the CloudStack upgrade, and then:

# service cloud-agent restart

and my agents reconnected to the management server without a hitch. I tested a few deploys and destroys and everything worked well. Zero VM downtime for any of my running VMs.

Again, you should follow the directions, make DB backups, etc, but you shouldn’t expect any issues on the 4.0.0->4.0.1 upgrade path.