liblvm Python/C extension (Python Liblvm)

liblvm Python/C extension (Python Liblvm)

[Killian De Volder]

@Lars,
I'm rather interested in this, have there been any updates ?

@The community,
Are there any plans for allowing python binding in the lvm-sources, or should this be a separate package ?
I also detect no way in lvm2app to create for example a snapshot. So I'm going to assume there is also need for work here.
Or is C binding of LVM generally a bad idea, and should we instead parse the lvm-tool output and communicate with LVM trough those means ?

Feedback is welcome of course.

Kind regards,
Killian De Volder

>  Hello,
>
>  I was missing a proper LVM2 interface to Python so I decided to write
>  one my self! I have wrapped all the liblvm C APIs (excluding the new
>  APIs committed in Dec). Doc strings are still missing, as well as proper
>  setup.py build env, so consider it as work in progress.
>
>  This might also be interesting to other projects like Anaconda for
>  example.
>
>  I would love to get your feedback on it!
>
>  Best regards,
>  Lars

liblvm Python/C extension (Python Liblvm)

[Lars Sjöström]

Hello,

I was missing a proper LVM2 interface to Python so I decided to write
one my self! I have wrapped all the liblvm C APIs (excluding the new
APIs committed in Dec). Doc strings are still missing, as well as proper
setup.py build env, so consider it as work in progress.

This might also be interesting to other projects like Anaconda for
example.

I would love to get your feedback on it!

Best regards,
Lars 

-----------------------------
Python example code:
-----------------------------

import liblvm

# create a new LVM instance 
lvm = liblvm.Liblvm()

# open a VG handle in write mode for 'myvg'
vg = lvm.vgOpen('myvg','w')

# remove a new LV (lv_foobar)
lv = vg.createLvLinear('lv_foobar',100000)

# print the uuid for the newly created LV
print lv.getUuid()

#print the size.
print lv.getSize()

# Add a tag to it.
lv.addTag("my_fance_tag")

# Print all tags.
print lv.getTags()

# Try to deactivate 
try:
	lv.deactivate()
except liblvm.LibLVMError:
	print "lets retry.."
	lv.deactivate()

# remove 
lv.remove()

# close VG handle
vg.close()

# close LVM handle
lvm.close()

-------------- next part --------------
A non-text attachment was scrubbed...
Name: liblvm.c
Type: text/x-csrc
Size: 28425 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20110120/e7f5ebc1/attachment.bin>

liblvm Python/C extension (Python Liblvm)

[Zdenek Kabelac]

Dne 20.1.2011 13:49, Lars Sj?str?m napsal(a):
> Hello,
> 
> I was missing a proper LVM2 interface to Python so I decided to write
> one my self! I have wrapped all the liblvm C APIs (excluding the new
> APIs committed in Dec). Doc strings are still missing, as well as proper
> setup.py build env, so consider it as work in progress.
> 
> This might also be interesting to other projects like Anaconda for
> example.
> 
> I would love to get your feedback on it!
> 
> Best regards,
> Lars 


I can see at least one problem - which needs to be addressed somehow.

Operations like lvremove are currently locking whole executable
to RAM - which is reasonable small (20MB) in case it's just native lvm binary,
but it may get unusable huge when Python steps in the game.

If the lvm2api is going to be used this way - we will need to add
some option  which would disable memlocking for this code - and user would
need to enable it probably explicitly.

Zdenek

liblvm Python/C extension (Python Liblvm)

[Petr Rockai]

Hi,

Lars Sj?str?m <lars.sjostrom@redhat.com> writes:
> I was missing a proper LVM2 interface to Python so I decided to write
> one my self! I have wrapped all the liblvm C APIs (excluding the new
> APIs committed in Dec). Doc strings are still missing, as well as proper
> setup.py build env, so consider it as work in progress.
>
> This might also be interesting to other projects like Anaconda for
> example.
>
> I would love to get your feedback on it!

I am not a python guy myself, but I definitely welcome this. On the
other hand, as Zden?k points out, this does have some issues. I also
think Anaconda folks have refused to use liblvm as far as there are no
python bindings (and they are not interested in binding to the C API
themselves). Hence, I suppose they are going to be interested indeed.

Nevertheless, there's another significant issue, and that is
maintenance. I can't commit to maintaining python bindings, since I have
responsibilities besides liblvm and I am a part-timer on LVM -- which
doesn't exactly leave much space for python (which would necessarily
include a lot of learning).

I'll try to talk with the rest of the team about how to best approach
this. There might be someone with the required python (and python
binding) skills and enough time. Alternatively, do you think you could
take the responsibility for the bindings yourself? As far as I recall,
there was talk of shipping python bindings (provided there were any, but
you obviously have some now) with the rest of LVM source (although I
have no idea what technical implications this may have for building
packages).

Yours,
   Petr

liblvm Python/C extension (Python Liblvm)

[Lars Sjöström]

On Mon, 2011-01-24 at 01:11 +0100, Petr Rockai wrote: 
> I am not a python guy myself, but I definitely welcome this. On the
> other hand, as Zden?k points out, this does have some issues. 

Zdenek has indeed a good point! How much work do you guys see to get
this sorted? (implement parameter for non-memlocking to RAM for certain
LVM commands/APIs.)    

> Nevertheless, there's another significant issue, and that is
> maintenance. I can't commit to maintaining python bindings, since I have
> responsibilities besides liblvm and I am a part-timer on LVM -- which
> doesn't exactly leave much space for python (which would necessarily
> include a lot of learning).
> 
> I'll try to talk with the rest of the team about how to best approach
> this. There might be someone with the required python (and python
> binding) skills and enough time. Alternatively, do you think you could
> take the responsibility for the bindings yourself? 

I'm indeed willing to take the maintenance ownership if you don't mind! 

As I said in earlier email, there is still work left. Doc strings,
proper packaging as well as add the new APIs that were released in
December.  

Should I continue and post updates?

Best regards,
Lars

liblvm Python/C extension (Python Liblvm)

[Zdenek Kabelac]

Dne 24.1.2011 10:58, Lars Sj?str?m napsal(a):
> On Mon, 2011-01-24 at 01:11 +0100, Petr Rockai wrote: 
>> I am not a python guy myself, but I definitely welcome this. On the
>> other hand, as Zden?k points out, this does have some issues. 
> 
> Zdenek has indeed a good point! How much work do you guys see to get
> this sorted? (implement parameter for non-memlocking to RAM for certain
> LVM commands/APIs.)    
> 

As we are currently redesigning a bit internal memlock code for some other
reasons, we may think about this support more. But as this piece of code is
quite sensitive and may have some 'hard to check' side effect I expect it take
some time.

Zdenek

liblvm Python/C extension (Python Liblvm)

[Zdenek Kabelac]

Dne 24.1.2011 01:11, Petr Rockai napsal(a):
> Hi,
> 
> Lars Sj?str?m <lars.sjostrom@redhat.com> writes:
>> I was missing a proper LVM2 interface to Python so I decided to write
>> one my self! I have wrapped all the liblvm C APIs (excluding the new
>> APIs committed in Dec). Doc strings are still missing, as well as proper
>> setup.py build env, so consider it as work in progress.
>>
>> This might also be interesting to other projects like Anaconda for
>> example.
>>
>> I would love to get your feedback on it!
> 
> I am not a python guy myself, but I definitely welcome this. On the
> other hand, as Zden?k points out, this does have some issues. I also
> think Anaconda folks have refused to use liblvm as far as there are no
> python bindings (and they are not interested in binding to the C API
> themselves). Hence, I suppose they are going to be interested indeed.
> 

I'm trying to get Anaconda team requirements in some written form - they are
doing many weird things which needs to be sorted out (currently they use some
rather very ugly hacks in their code) - I believe they do not need to handle
things in python at all as they do now and they should be happy with lvm2cmd
library - IMHO they need some virtual LVM support - but let's wait what will
they provide to us.

Zdenek