Bug 1489590 - LVM libraries: deprecate libraries - inform users they will not be supported beyond RHEL7
Summary: LVM libraries: deprecate libraries - inform users they will not be supported ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Marian Csontos
QA Contact: cluster-qe@redhat.com
Marek Suchánek
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-07 20:15 UTC by Jonathan Earl Brassow
Modified: 2021-05-05 14:18 UTC (History)
11 users (show)

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++.
Clone Of:
Environment:
Last Closed: 2018-11-08 16:16:44 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.