liblvm/python-lvm behavior

liblvm/python-lvm behavior

[Tony Asleson]

In liblvm the user is required to follow any changes with a lvm_vg_write
to make the change persistent.  Internally, lvm_vg_write does a vg_write
and vg_commit.  In the python bindings most of the modification methods
do this automatically.  Currently the python bindings do not expose the
lvm_vg_write functionality.  For those methods that don't implicitly
call lvm_vg_write we appear to have no way to make those changes
persistent unless you call another vg modification method that does an
implicit lvm_vg_write.  This needs to be corrected.

A further complication is that in the C API the user could do:

vg = lvm_vg_create( library_handle, "vg_name");
lvm_vg_write(vg);
lvm_vg_close(vg);
lvm_quit(library_handle);

expecting that the newly created vg will exist, but it doesn't until you
have at least added one PV via lvm_vg_extend.  Currently a user does not
get any errors in this use case either.

What should be done to make this all consistent?  If we want to continue
with the implicit lvm_vg_write in all python methods we need to change
the signature of lvm_vg_create to require at least 1 device.  Otherwise,
we could remove all the implicit lvm_vg_write calls in the python
bindings and expose it.  This would then require python users to make
explicit calls to lvm_vg_write to make the changes persistent as the C
library currently requires.

Note: Please remember that eventually we want to support "dry run" mode
too, so that may factor into some of the design decisions on how we want
to deal with this.

Thanks!

Regards,
Tony

liblvm/python-lvm behavior

[Andy Grover]

On 10/24/2012 01:58 PM, Tony Asleson wrote:
> What should be done to make this all consistent?  If we want to continue
> with the implicit lvm_vg_write in all python methods we need to change
> the signature of lvm_vg_create to require at least 1 device.  Otherwise,
> we could remove all the implicit lvm_vg_write calls in the python
> bindings and expose it.  This would then require python users to make
> explicit calls to lvm_vg_write to make the changes persistent as the C
> library currently requires.

Yes I think we should not expose vg_write to library users. The fact
that it is created as an in-memory struct that is then extended to
include its first pv and then written, doesn't need to be exposed since
skipping any of those steps is incorrect.

So I'd like to see lvm_vg_create take a single path to a vg as a
required parameter. I don't think we need to take multiple pv paths, we
can extend to them after lvm_vg_create returns easily enough.

Regards -- Andy