[linux-lvm] LVM2APP still under active development?

[linux-lvm] LVM2APP still under active development?

[Bram Klein Gunnewiek]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

Hello,

I'm developing an in-house application that needs to control LVM set-ups. I
was looking at the lvm2app API but its missing a couple of features I need
(snapshots, resizing logical volumes (API is defined but not implemented),
...). I can't find any road-map or document with plans for the API (only
the v1 document at http://fedoraproject.org/wiki/LVM/liblvm ).

Is the API still under active development, and are new features added? I
rather use a stable API instead of wrapping around CLI commands, but mixing
the two to use the functionality the API is missing doesn't seem a smart
option to me.

[-- Attachment #2: Type: text/html, Size: 708 bytes --]

Re: [linux-lvm] LVM2APP still under active development?

[Tony Asleson]

On 10/02/2012 04:42 AM, Bram Klein Gunnewiek wrote:
> Hello,
> 
> I'm developing an in-house application that needs to control LVM
> set-ups. I was looking at the lvm2app API but its missing a couple of
> features I need (snapshots, resizing logical volumes (API is defined
> but not implemented), ...). I can't find any road-map or document
> with plans for the API (only the v1 document at
> http://fedoraproject.org/wiki/LVM/liblvm ).
> 
> Is the API still under active development, and are new features
> added?

The API is getting some attention.  Current plan is to add feature
parity python bindings to API (patches pending) and then add features to
the API.  Some of the initial planned improvements include:

- PV (create/resize/remove/enumerate & query)
- VG (activate/deactivate)
- LV (Ability to enumerate information directly without enumerating VGs
  first)
- Dry run feature,  the ability to do multiple changes while checking
  for errors and examine the end resulting end configuration before
  applying changes

The long term goal is to achieve feature parity with the command line.

> I rather use a stable API instead of wrapping around CLI commands,
> but mixing the two to use the functionality the API is missing
> doesn't seem a smart option to me.

We agree.

Regards,
Tony