Hi all,

Just reading through Luke's interview on computerworld.com.au and I came across this statement:

"This topic comes up on the list periodically, however, and most people are very tight-lipped about what they're doing with Puppet."

Being the chattermouth that I am, I'd like to take this opportunity to tell you all what we're (that is, my company, Cidev, based in The Netherlands) doing with Puppet and why we like it. Even though I've only started using it about a week ago...

Our new customer (which I'm not going to name at this time, but you probably haven't heard of him, because it's a pure b2b company) needed a high-available setup, consisting of 14 servers and providing several services like web, servlets, database, you name it. Think about your ideal web platform, add some proprietary stuff and that's basically it. Required uptime: 99.9999999% (we only offered 99.99% though).

In the years doing service maintenance we've learned the power of virtualisation. Even when a server only provides 1 service, we put it in a virtualised environment. It helps a lot in maintenance and general "stuff you can do at a distance". I.e. updating kernels, if you want to be really sure it doesn't give you downtime, requires a test setup and usually your direct presence or remote console stuff. With Xen (the virtualisation we use) we can do it simply from the dom0. There's more, but, since Puppet is a sysadmin tool and I expect most of you to be sysadmins, you can probably think of some stuff yourself.

But, that also means you at least duplicate the number of servers you maintain. So 28 servers needed to be maintained. We splitted some services onto their own virtual domain, for safety, so that can amount quickly to 35~40 servers in the end. Ow and they have to be ready yesterday. Yeah, we know you had to start two weeks late because the machines were delivered late and Internet wasn't available for two week, but we still got our deadlines. Well... needless to say, not only did we need a convenient way to adminster the servers, we also needed fast deployment.

Now, xen-create-image (on Debian at least) supports roles, which are basically scripts that can do some stuff after installation to fix up the installation the way you want it. Great. It took me almost two days to create a role that did exactly what I wanted, create a basic installation the way we do it. Then I switched to puppet. I learned puppet and recreated the basic installation script in one day. And now we got advanced config replication foo. That's important since high-availability means you have several servers configged exactly the same.

A deadline passed today and I'm quite sure I only made it because of the use of Puppet. It still took me to 3.30am last night, but once I had one server running, I only needed to add the script to the other servers which were supposed to be about the same. Done. Loadbalancing, webserver, HA-NFS working.

Thank you for Puppet!

Now, for my wishlist, Santa! What I would like to see support for in Puppet: - LVM (I need to create large amounts of partitions, would be great if I could do that centrally and no, sorry, the RH conga framework doesn't work for me) - DRBD (if we can make the partitions, we can network-raid-1 them...) - Xen domU (just a convenient way to create domU *configs*, not create the entire image, since I guess that would be a bit difficult) - Xen domU (the entire image... yeah, it's a wishlist so why not) - apt-get --purge option - apt-get dist-upgrade (preferably on demand only) - report-back framework (oh noes! client 375 had an error while trying to run manifest Foo, let's have the puppetmaster mail the Sysadmin Donkey so he can fix it) - nagios integration (I can dream, can't I?) - support for something like:

exec { "mycommand with some arguments": unless => file { "/tmp/idonotexists": test => exists } }