LVM support

Scott Seago did something along those lines a while ago (http://hg.et.redhat.com/hg/emd/libraries/puppet-conga-types) though that hasn't seen all that much use. It would be great to revive that work.

Scott's original announcement is at http://mail.madstop.com/pipermail/puppet-dev/2006-August/001552.html and I'll attach the README from that mail here.

David: The problem with Scott's LVM work is that it's predicated on having that Conga stuff around, which is all RedHat specific (or at least, it doesn't exist in any distro I use). That's why it hasn't gotten much use in my world.

Tim: I've got work on the cards to build some LVM management types, but the fundamental operations you've specified there are quite ambiguous.

For example, not all filesystems support online resizing. Worse still, some filesystems might support online resizing, depending on what kernel patches, tool versions, creation options, and phase of the moon you've got. What happens if we can't online-resize? Do we resize the LV and leave the filesystem alone? (Pointless, IMO). Do we unmount and resize? I think there are some filesystems that you can't resize at all. What do we do then? Should the Puppet type have knowledge of all possible filesystems and their capabilities? (Not even possible in the case of ext2/3, given the above kernel patch madness).

What about the filesystem type being wrong? I'd imagine that just summarily running mkfs on the block device would be considered Wrong, but what else is Puppet supposed to be able to do? You haven't said what action to take if it's incorrect, but there's not a lot of point in checking it if you don't do something about it.

You've got extra risks when you're running DRBD, too -- there's a number of changes to the block device that can't be undertaken without notifying the other member(s) of the cluster, and in some cases shutting down the replication and performing additional administrative work on all the machines in the cluster. (Personally, I gave up DRBD as a cruel hoax on sysadmins some years ago).

I'd like your input on these issues (and more), because I've been wrestling with them for a while now and I can't make heads or tails of them, and without sensible answers I can't get very far in the code.

Given that we could implement Conga as a provider for filesystems, it shouldn't be hard to migrate Scott's work into core, and still provide support for a native provider. That migration should be the first step, I think.