Puppet: System Administration Automated

Support

Ticket #475 (new enhancement)

Opened 2 years ago

Last modified 7 months ago

LVM support

Reported by: tim Assigned to: community
Priority: normal Milestone: unplanned
Component: newfeature Version:
Severity: normal Keywords:
Cc: Triage Stage: Needs design decision
Attached Patches: None Complexity: Unknown

Description

I'd like to see a way to create/manage LVM partitions from puppet. This would be convenient when one uses DRBD from within a Xen domU. The code should:

  • Check if a given LVM partition exists,
  • Check if a given LVM partition is of the correct size and if not, resize it,
  • Check if a given LVM partition contains the desired filesystem.

Thank you.

Attachments

README (2.9 kB) - added by lutter on 02/03/07 18:54:44.

Change History

02/03/07 18:54:22 changed by lutter

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.

02/03/07 18:54:44 changed by lutter

  • attachment README added.

02/03/07 22:37:12 changed by mpalmer

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.

04/05/07 22:41:38 changed by luke

  • specification set to None.
  • patch set to None.
  • complexity set to Unknown.
  • milestone set to unplanned.
  • owner changed from luke to community.
  • approval set to Approved.
  • compatibility set to Unknown.
  • stage set to Needs design decision.

05/09/07 02:29:50 changed by luke

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.

04/24/08 07:38:31 changed by luke

  • component changed from library to unknown.

04/28/08 16:34:34 changed by jamtur01

  • component changed from unknown to newfeature.