Bug 1489590

Summary:	LVM libraries: deprecate libraries - inform users they will not be supported beyond RHEL7
Product:	Red Hat Enterprise Linux 7	Reporter:	Jonathan Earl Brassow <jbrassow>
Component:	lvm2	Assignee:	Marian Csontos <mcsontos>
lvm2 sub component:	Python API / liblvm	QA Contact:	cluster-qe <cluster-qe>
Status:	CLOSED CURRENTRELEASE	Docs Contact:	Marek Suchánek <msuchane>
Severity:	unspecified
Priority:	unspecified	CC:	aarnold, agk, heinzm, jbrassow, lkuprova, mcsontos, msnitzer, prajnoha, rhandlin, tasleson, zkabelac
Version:	7.3
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Deprecated Functionality
Doc Text:	.LVM libraries and LVM Python bindings have been deprecated The `lvm2app` library and LVM Python bindings, which are provided by the `lvm2-python-libs` package, have been deprecated. Red Hat recommends the following solutions instead: * The LVM D-Bus API in combination with the `lvm2-dbusd` service. This requires using Python version 3. * The LVM command-line utilities with JSON formatting. This formatting has been available since the `lvm2` package version 2.02.158. * The `libblockdev` library for C and C++.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-11-08 16:16:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jonathan Earl Brassow 2017-09-07 20:15:48 UTC

Time to inform users that RHEL7 will be the last with python/liblvm2app library support.

1) Header files, etc will be removed from the next Fedora builds
2) We will need deprecation documentation (release note?)
3) Pull libraries from 7.5?
4) No support for these libraries beyond RHEL7

Comment 2 Peter Rajnoha 2017-09-08 07:52:17 UTC

Just a note that our own lvm2-activation-generator for systemd (found in scripts/lvm2_activation_generator_systemd_red_hat.c) uses lvm2app to read the lvm2 config.

So we need to find an alternative for that. The only one at the moment I can think of quickly is to call something like 'system("/usr/sbin/lvmconfig --type current ...")'. The other option is to share the code somehow better so we can read the config in lvm2-activation-generator directly without a need to call external command.

Comment 3 Marian Csontos 2017-09-08 08:23:36 UTC

We will just remove headers (and .so) from the devel sub package.

Comment 4 Peter Rajnoha 2017-09-08 09:09:13 UTC

(In reply to Marian Csontos from comment #3)
> We will just remove headers (and .so) from the devel sub package.

Well, the .so is not in the devel subpackage, it's in lvm2-libs subpackage actually. So you'd remove the lvm2app altogher...

...as another alternative - we can add an option for vgchange (lvchange) -aay to exit immediately if lvmetad is running (and hence autoactivaiton works via pvscan -aay call from udev) and do the activation if lvmetad is not running, something like:

  vgchange -aay --skip-if-lvmetad-running ....

Then we don't need the lvm2-activation-generator and we'd just add the units with vgchange calls directly and unconditionally.

(Of course, eventually, this should be covered by SID completely. So I mean this for the period of time we move to SID.)

Comment 5 Peter Rajnoha 2017-09-08 10:20:25 UTC

See also:

# dnf repoquery --whatrequires lvm2-libs
collectd-lvm-0:5.7.2-12.fc27.x86_64
glusterfs-server-0:3.12.0-1.fc28.i686
glusterfs-server-0:3.12.0-1.fc28.x86_64
lvm2-0:2.02.173-4.fc27.x86_64
lvm2-devel-0:2.02.173-4.fc27.i686
lvm2-devel-0:2.02.173-4.fc27.x86_64
lvm2-python-libs-0:2.02.173-4.fc27.x86_64
lvm2-python3-libs-0:2.02.173-4.fc27.x86_64

So we need to check the collectd and glusterfs-server how they use the lvm2-libs.

Comment 6 Tony Asleson 2017-10-05 20:46:48 UTC

Also ...

# dnf repoquery --whatrequires lvm2-python3-libs
targetd-0:0.8.6-3.fc27.noarch

and

# dnf repoquery --whatrequires lvm2-python-libs
targetd-0:0.8.6-1.fc26.noarch

Comment 7 Alasdair Kergon 2017-10-16 17:19:50 UTC

This bug is just about notifying users to prepare them for a future change.  Discussion of the actual change should happen elsewhere.

Comment 8 Alasdair Kergon 2017-10-16 17:22:13 UTC

We're not removing anything from the RHEL7.5 packages.

We could consider compile-time and/or run-time warnings - probably just compile-time.

Comment 9 Marek Suchánek 2017-12-06 14:00:45 UTC

Hello Marian,

I'm preparing the RHEL 7.5 Release Notes. Do we want to include a note about LVM libraries deprecation there?

If so, could you please give me more information about the impact of the deprecation and whether an alternative exists that users can switch to?

Thanks,

Marek

Comment 10 Marek Suchánek 2018-03-14 13:35:34 UTC

Marian, thanks for the draft doc text. I've edited it, trying to preserve all the technical information in place.

If you have any comments or suggestions regarding the doc text, please let me know. Otherwise, we're ready to publish it as it is.