Re: [linux-lvm] Proposal for the libLVM project

Re: [linux-lvm] Proposal for the libLVM project

[Alasdair G Kergon]

Thanks for getting in touch.

The only library supported for external applications at present is
liblvm2cmd and this is basically a wrapper around the command line.
This was a deliberate decision to force people to use the only stable interface
we have, namely the command line.

The lvm library that came with the original version of LVM had many problems
and when we began LVM2 we made the decision not to offer a library until the
code base and interfaces settled down.  We've had discussions (undocumented
unfortunately - snippets on irc and face-to-face discussions) about what
form the library API should take and reached a basic consensus.  Every
change made to the code is done with these plans in mind.
More recently, we've been moving some functions out of lvm and into
libdevmapper - which is a supported library interface.

The current split between the 'lib' and 'tools' directory is not
particularly well-defined at the moment, and there's some more code
in 'lib' that should be in 'libdevmapper', behind a decent interface.


The end result should be:

  a new lvm library API exists which is designed to be maintainable as the
tools develop and not cause compatibility problems or inhibit anticipated
future developments;

  the tools directory uses only the published API;

  everything available in the API is available directly through the lvm
command line - there must be no 'hidden' features;

  no internal structures are exposed through the library API so we retain
complete freedom to change internal implementations and data structures.

Note that last one carefully - structures in metadata.h are not to be
exposed directly: the file is still very much a 'work in progress'.
PV and LV structures are gradually merging; the VG concept is undergoing
change - and this will all be done without breaking the existing
command line interface, though there'll be extensions to it, and the
library has to be similarly stable and maintainable.  The existing
liblvm.a is not the right basis to base this work on - if anything,
what's happening is a supportable wrapper library is being designed
over the top of it.

So yes, I'm anticipating something object-based: get a handle for a PV,
create a VG by supplying handles for the PVs to go into it and getting a
handle for the VG back.  Get properties of an object by supplying the
appropriate method with the appropriate handle etc.


The first job is to sketch out possible interfaces for some examples
like that - 'create a PV', 'create/extend a VG' - based on what the tools
do today.

Further, if there are things that parted wants that are not available
through the command line today, then put those on the table ASAP and
we should try to get them implemented through the command line (in parallel
with work on designing a library).


There's a separate mailing list for LVM development (which I'll announce
properly in another message), and further discussion should happen there:
please remove linux-lvm from follow-ups about the details of the library.

  https://www.redhat.com/mailman/listinfo/lvm-devel

Alasdair
-- 
agk@redhat.com

[linux-lvm] Proposal for the libLVM project

[Anant Narayanan]

Hi!

This is regarding a proposal to improve the lvm-tools package currently 
offered by Red Hat. Although your package is an excellent set of tools 
for managing LVM systems, we have found that the codebase is too 
specific to the several LVM Applications that are bundled with your 
distributions.

In the best interest of the community, we feel it would be best to take 
the development of the lvm-tools package in the direction of a more 
generic library - liblvm. The major driving force behind this reasoning 
is the fact that managing LVM setups is a large enough task to warrant a 
separate library. There are several advantages to this approach:

1) Keeping the library and application parts separate. Needless to say, 
this goes a long way in keeping code clean, by preventing the needs of 
the application or library to interfere with each other.

2) Providing a general library for use by other applications that deal 
with LVM setups. This not only encourages alternate LVM-based 
applications to spring, but also invites a larger part of the community 
to contribute back to the development of liblvm (now lvm-tools).

The 2nd point is what concerns us, the GNU Parted team. GNU Parted 
currently deals with block devices only, and therefore cannot operate on 
LVM setups. We concluded that the creation of a library such as liblvm 
would help a lot in adding support for LVM setups.

Here is a rough plan of our intentions:

- Fork the lvm-tools project into liblvm
   (If Red Hat expresses interest in the concept of liblvm, then the 
project may be hosted by Red Hat, and we will provide developers to help 
you. Else, we host the project ourselves)

- Separate the command-line utilities and application-specific code from 
the codebase.

- Formulate (actually complete) a formal API that would be most useful 
for applications that use the library.

- Build the library to be generic as planned, and modify all 
applications currently depending on it (the command-line utilities and 
the Red Hat LVM Application) suitably.

- Use the new library to add LVM support to GNU Parted.

Do let us know what you think of this.

Best Regards,

The GNU Parted Team

Re: [parted-devel] Re: [linux-lvm] Proposal for the libLVM project

[Otavio Salvador]

[ I've removed linux-lvm from cc list but leave parted-devel since
it still on topic]

Alasdair G Kergon <agk@redhat.com> writes:

> Thanks for getting in touch.
>
> The only library supported for external applications at present is
> liblvm2cmd and this is basically a wrapper around the command line.
> This was a deliberate decision to force people to use the only stable interface
> we have, namely the command line.

Right. Is this library being still maintained?

> The end result should be:
>
>   a new lvm library API exists which is designed to be maintainable as the
> tools develop and not cause compatibility problems or inhibit anticipated
> future developments;
>
>   the tools directory uses only the published API;
>
>   everything available in the API is available directly through the lvm
> command line - there must be no 'hidden' features;

I completely agree with you here.

>   no internal structures are exposed through the library API so we retain
> complete freedom to change internal implementations and data structures.

Indeed.

> The first job is to sketch out possible interfaces for some examples
> like that - 'create a PV', 'create/extend a VG' - based on what the tools
> do today.

Indeed. How do you wish to coordenate this? Should we propose those to
mailing list? Or should us use something like a wiki?

> Further, if there are things that parted wants that are not available
> through the command line today, then put those on the table ASAP and
> we should try to get them implemented through the command line (in parallel
> with work on designing a library).

I don't think so. On parted side we'll probably write another layer
that will be used to "connect" the libparted on external libraries. It
won't be done just for lvm but also for other filesystems like
ext[34], and other's will come later.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
---------------------------------------------
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: [parted-devel] Re: [linux-lvm] Proposal for the libLVM project

[Alasdair G Kergon]

On Fri, Nov 10, 2006 at 10:21:48AM -0200, Otavio Salvador wrote:
> Alasdair G Kergon <agk@redhat.com> writes:
> > The only library supported for external applications at present is
> > liblvm2cmd and this is basically a wrapper around the command line.

> Right. Is this library being still maintained?
 
Yes.

> > The first job is to sketch out possible interfaces for some examples
> > like that - 'create a PV', 'create/extend a VG' - based on what the tools
> > do today.
> Indeed. How do you wish to coordenate this? Should we propose those to
> mailing list? Or should us use something like a wiki?
 
Mailing list is probably easiest, or wiki for editing with mailing list
posts every so often for people not wanting to watch every individual
wiki edit.

Alasdair
-- 
agk@redhat.com