As the post title suggests, though, I think ‘foil ball’ is a more appropriate term.

You have significant problems when you rely on golden images:  Image sprawl, updating your images, and image state vs. running state.

Image sprawl is what you get when the number of images (not running virtual machines) you have grows to an essentially unmaintainable figure.  Let’s start with a simple LAMP stack:  At the least, you’ll have a separate image for your web, database, and application servers.  Oh, except you probably need a load balancer image.  If you have any support services like DNS, you need an image for those.  And so on.  You soon find that you have a separate image for every service you provide.

Now that you’ve got this image sprawl, you run into the next issue:  Updating these images is relatively expensive, and nearly always results in redundancy.  It’s expensive because even trivial changes require a full image rebuild, which is itself a bit complicated.  The redundancy comes because you *still* have to do some work on the image once it’s booted as a server, even if it’s minimal.  So now you’ve got this complicated image generation process that has some kind of overlap with a simple on-server management process.  Another kind of redundancy arrives when you make a change that affects multiple images (e.g., upgrading the same package, or performing the same configuration change): you have to make this change to each of these images separately.

Oh, and by the way – this updating process is usually completely unrelated to the process you use to update your non-image machines.  Because hey, if a little bit of redundancy is good, then redundant redundancy is especially awesome.

Say you managed all of that, though, and all of your images are correctly updated all of the time.  Great, now you just have to reboot every machine on your network to take advantage of the new changes.  Of course, this isn’t exactly feasible for every machine all the time, which means you’ve got drift between the desired and actual configuration state.

This is why I think maintaining these images is more like managing a foil ball:  It’s difficult to pull apart, difficult to press back together, and if you get too many of them they just get into the way.

If, instead, you use a single, base image for all of your work — I call these images stem cell images for what are hopefully obvious reasons – and then use a tool like Puppet to configure them once they’re running, you avoid all of the above problems:  You have one image to maintain and it’s necessarily simplistic, you use the same tool and the same configuration base across all images, and Puppet keeps your machines updated within 30 minutes of any central change.

So, if someone tries to sell you a golden image, don’t buy it – instead choose a tool you can use for every machine in your organization, and push every configuration operation possible into that tool, rather than spreading tasks around to your provisioning, image management, and configuration management tools.  This is just as true for tools like Jumpstart and Kickstart – they should do as little as possible, and hand off immediately to a tool like Puppet; well, really, just Puppet.

…this step is another milestone for the openQRM project which now includes the automatic configuration management features for the managed appliances powered by Puppet. With integrating Puppet into openQRM the mission is to provide a generic web-based user interface for the Puppet manifest. The current state already provides some pre-made classes like web-server, database-server, lamp etc. and automatically sets up Puppet for the openQRM environment in best-practice  manner by keeping the manifest in an snv-repository.

John Willis had a say, too:

The important thing, in my opinion, about the the openQRM Puppet integration transaction is that it exposes the exciting and beautiful things about open source. From a discussion about the importance of the integration of provisiong and configuration management, (i.e., openQRM and Puppet), to a fully developed integrated solution, only took 3 weeks. Imagine this discussion happening between even the most agile of proprietary vendors and the time line of something like this to happen. In the proprietary example they would still be playing phone tag just to figure out how their lawyers could talk. I am pretty sure Matt never even called Luke once during that whole process.

I haven’t yet had the chance to give OpenQRM a try, but hopefully this will encourage others to try it, and maybe one of those others will let me know how it goes for them.

Except not at LISA.  Check a Twitter Search, for example — very few twitterers, almost none about the actual sessions, and no visibility within LISA of any twittering.  Or blogging.  This is the first conference I’ve gone to in ages that didn’t have a standard tag mentioned for blogging et al, which makes it hard to find blogs about a conference named ‘LISA’.  Technorati finds 7 results, but most of those seem to be about a completely different conference.

It’s very frustrating, because it’s still one of the best conferences to go to as a sysadmin (although Velocity is quickly becoming better), but the attendees don’t seem to be pushing the conference, and the conference definitely isn’t pushing the attendees.

I’m once again friends with the guy running the conference, Adam Moskowitz, so hopefully I can pressure him into making it a bit more online somehow.  I’m not sure there’s much he can do, though — he needs to somehow get the community interested, and one thing we’ve pretty clearly established is that we don’t have much of a community.