"lv_attr" disappeared from lvm_lv_get_property?

"lv_attr" disappeared from lvm_lv_get_property?

[Marius Vollmer]

Hi,

at one moment lvm_lv_get_property returned a valid and useful "lv_attr"
property, and then suddenly it returns values with "is_valid == 0".

I think it works with lvm2-2.02.111-1.fc21.x86_64 and am sure it fails
with lvm2-2.02.115-1.fc21.x86_64.

Furthermore, lvm_lv_get_attr, which might be the right function to use
in the first place, returns a incomplete value like "twi-XXtz--" where
the 'active' and 'open' fields are set to "unknown".

The lvs command still displays the correct values with "lvs -o lv_attr".

What in the name of holy backwards compatibility is going on here?

"lv_attr" disappeared from lvm_lv_get_property?

[Alasdair G Kergon]

On Thu, Jan 29, 2015 at 09:50:08PM +0200, Marius Vollmer wrote:
> at one moment lvm_lv_get_property returned a valid and useful "lv_attr"
> property, and then suddenly it returns values with "is_valid == 0".
 
The way some of the properties are gathered got changed.

Sounds like we forgot to update the library code to use the new method...

Alasdair

"lv_attr" disappeared from lvm_lv_get_property?

[Marius Vollmer]

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

> On Thu, Jan 29, 2015 at 09:50:08PM +0200, Marius Vollmer wrote:
>> at one moment lvm_lv_get_property returned a valid and useful "lv_attr"
>> property, and then suddenly it returns values with "is_valid == 0".
>
> The way some of the properties are gathered got changed.
>
> Sounds like we forgot to update the library code to use the new method...

I found this:

    /* backward compatible internal API for lvm2api, TODO improve it */
    char *lv_attr_dup(struct dm_pool *mem, const struct logical_volume *lv)

Guys, really.  Write some tests.

"lv_attr" disappeared from lvm_lv_get_property?

[Zdenek Kabelac]

Dne 29.1.2015 v 21:24 Marius Vollmer napsal(a):
>
> Alasdair G Kergon <agk@redhat.com> writes:
>
>> On Thu, Jan 29, 2015 at 09:50:08PM +0200, Marius Vollmer wrote:
>>> at one moment lvm_lv_get_property returned a valid and useful "lv_attr"
>>> property, and then suddenly it returns values with "is_valid == 0".
>>
>> The way some of the properties are gathered got changed.
>>
>> Sounds like we forgot to update the library code to use the new method...
>
> I found this:
>
>      /* backward compatible internal API for lvm2api, TODO improve it */
>      char *lv_attr_dup(struct dm_pool *mem, const struct logical_volume *lv)
>
> Guys, really.  Write some tests.
>


Hi


lvm2api is rather purely experimental part of lvm2 - it has no real maintainer
and no real plans on further development ATM.

I'd strongly recommend to use lvm2 commands - since they are far more 
optimized and tested.

lvm2api at current stage has huge list of hardly resolvable issues and some 
new way has to be used to fix them (likely some 'client/server' model)

Regards

Zdenek

"lv_attr" disappeared from lvm_lv_get_property?

[Marius Vollmer]

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

> Sounds like we forgot to update the library code to use the new method...

I filed a bug for this:

    https://bugzilla.redhat.com/show_bug.cgi?id=1187481

Let us know how we are going to fix this.  If lvm2app is really a lost
cause, we can change storaged to fork lvs etc and parse it's output.

"lv_attr" disappeared from lvm_lv_get_property?

[Peter Rajnoha]

On 01/30/2015 08:51 AM, Marius Vollmer wrote:
> Alasdair G Kergon <agk@redhat.com> writes:
> 
>> Sounds like we forgot to update the library code to use the new method...
> 
> I filed a bug for this:
> 
>     https://bugzilla.redhat.com/show_bug.cgi?id=1187481
> 

Unfortunately, this was a regression introduced in LVM2 v115. It should
be fixed now (https://bugzilla.redhat.com/show_bug.cgi?id=1187481#c2).

> Let us know how we are going to fix this.  If lvm2app is really a lost
> cause, we can change storaged to fork lvs etc and parse it's output.

I wouldn't say lvm2app is unusable, it's just not as maintained and
refreshed as direct LVM tools. The bug above was just a silly regression
that happened (yes, we should add full test coverage to lvm2app - that's
currently missing, I admit).

Also, recently, we've added tons of new fields, also fields for
reporting each attribute in its own field so you have easier job
when parsing the output (see lvs/vgs/pvs -o help). However,
some of these new fields doesn't have lvm2app hooks yet written -
they're going to be added soon.
-- 
Peter

"lv_attr" disappeared from lvm_lv_get_property?

[Marius Vollmer]

Peter Rajnoha <prajnoha@redhat.com> writes:

> Unfortunately, this was a regression introduced in LVM2 v115. It should
> be fixed now (https://bugzilla.redhat.com/show_bug.cgi?id=1187481#c2).

Thanks!  (I think there is more to do, unfortunately, see the bug.)

> I wouldn't say lvm2app is unusable, it's just not as maintained and
> refreshed as direct LVM tools. [...]

Do you know of any users besides storaged?

We should cooperate and make somehow sure that the storaged and Cockpit
tests run for each LVM2 update...

"lv_attr" disappeared from lvm_lv_get_property?

[Peter Rajnoha]

On 01/30/2015 10:32 AM, Marius Vollmer wrote:
> Peter Rajnoha <prajnoha@redhat.com> writes:
> 
>> Unfortunately, this was a regression introduced in LVM2 v115. It should
>> be fixed now (https://bugzilla.redhat.com/show_bug.cgi?id=1187481#c2).
> 
> Thanks!  (I think there is more to do, unfortunately, see the bug.)
> 

(yup, I'm looking at that now)

>> I wouldn't say lvm2app is unusable, it's just not as maintained and
>> refreshed as direct LVM tools. [...]
> 
> Do you know of any users besides storaged?
> 

Anaconda was one of the candidates to use liblvm, but afaik, they're
still forking LVM commands.

The other one I know of is the udisks, but it removed support for LVM
some time ago and udisks2 and later does not handle LVM anymore.

And then your use case :)

I don't know about more lvm2app users (but if anyone knows about more,
correct me) at the moment. That's also the reason why we (or I) don't
invest so much time into this and we spend this time on improving direct
LVM commands instead, I'd say.

> We should cooperate and make somehow sure that the storaged and Cockpit
> tests run for each LVM2 update...

...and we (LVM) should add more tests into our testsuite for the lvm2app.

-- 
Peter

"lv_attr" disappeared from lvm_lv_get_property?

[Peter Rajnoha]

On 01/30/2015 10:42 AM, Peter Rajnoha wrote:
> On 01/30/2015 10:32 AM, Marius Vollmer wrote:
>> Do you know of any users besides storaged?
>>
> 
> Anaconda was one of the candidates to use liblvm, but afaik, they're
> still forking LVM commands.
> 
> The other one I know of is the udisks, but it removed support for LVM
> some time ago and udisks2 and later does not handle LVM anymore.
> 
> And then your use case :)

+2 more - collectd and glusterfs-server, at least on Fedora:

[1] f21/~ # repoquery --whatrequires lvm2-libs
collectd-lvm-0:5.4.1-8.fc21.x86_64
glusterfs-server-0:3.5.3-1.fc21.x86_64
storaged-0:0.3.1-1.fc21.x86_64

-- 
Peter