 |
Any news about this?. For people like us that uses GFS and clvm, the severity is high. Thanks very much. |
|
|
Could this package be added to the HighAvailability repo? Isn't this a dependency for the pcs package? |
|
|
This also effects me greatly, and saddens me that there's been no change or update to this bug. |
|
|
The `dlm` package is required for using `lvmlockd` (the new replacement for clvmd) with shared LVM volumes and GFS2 per Red Hat documentation and the lvmlockd man page: - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_and_managing_high_availability_clusters/index - http://man7.org/linux/man-pages/man8/lvmlockd.8.html Additionally, it's possible to use shared (exclusively activated) LVM filesystems without GFS2 in the Pacemaker cluster as a use case; the resource control script is owned by the Pacemaker package and it's what runs the "dlm_controld" process which is in the dlm RPM file (not dlm-lib): # rpm -qf /usr/lib/ocf/resource.d/pacemaker/controld pacemaker-2.0.2-3.el8.x86_64 # rpm -qf /usr/sbin/dlm_controld dlm-4.0.9-3.el8.x86_64 We need the `dlm` package in the CentOS channels as it is with real RHEL, it's required for specific use cases - it provides `dlm_controld` and `dlm_tool` binaries amongst others. It's not marked as a hard dependency from the `lvm2-lockd` RPM as the new lvmlockd solution _can_ work with an alternate mode called "sanlock" (see man page) but this is not used in Pacemaker/corosync - DLM is used and requires dlm_controld under the hood. |
 |
I am sorry .. that package is not in RHEL .. we have released what is in RHEL .. I don't have permission to release things in other repositories. |
|
|
What repo is it in then? It certainly isn't EPEL, and it most definitely was in RHEL 7's repo... |
|
|
Hi Johnny, I just lost everything I typed due to this bug tracker timing out the session on me, so I'll cut to the last part I wrote - in RHEL7 and RHEL8 both, the dlm package is in the Resilient Storage child channel. CentOS 7 published the dlm package in the main repos: https://mirrors.edge.kernel.org/centos/7/os/x86_64/Packages/ ...so what's changed with CentOS 8 legal posturing, and should you go back and strip it out of CentOS 7? It's in the exact same location upstream in RHEL. This is a critical-path package required for some of us to set up Pacemaker clusters and is a must-have, not a nice-to-have. BTW - all the Pacemaker packages are in High Availability in real RHEL, a sister channel to Resilient Storage (same design pattern) - and CentOS 8 is publishing all of them. By this logic, why does the CentOS 8 HighAvailability child channel exist, shouldn't everything in it be following the stated reason DLM is not provided? https://mirrors.edge.kernel.org/centos/8/HighAvailability/x86_64/os/Packages/ Everything in there is in a child channel in real RHEL, not Base/Appstream. |
|
|
I'd also note here that Koji is building DLM and it's publicly available with a simple curl/wget: https://koji.mbox.centos.org/koji/buildinfo?buildID=4801 We have to do this because the child package `dlm-lib` is in Base/Appstream. |
|
|
It's also worth noting that both dlm & dlm-lib are built from the same source package - which you have definitely published at http://vault.centos.org/8.1.1911/BaseOS/Source/SPackages/dlm-4.0.9-3.el8.src.rpm The only difference between the RHEL 8 Resilient Storage and High Availability channels is the presence of the cmirror and dlm packages in Resilient Storage See https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/high-availability-addon vs https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/package_manifest/resilient-storage-addon cmirror is part of the lvm2 source, which is published at http://vault.centos.org/8.1.1911/BaseOS/Source/SPackages/lvm2-2.03.05-5.el8.0.1.src.rpm (and you can see it built at https://koji.mbox.centos.org/koji/buildinfo?buildID=6249) As already stated - dlm is a prerequisite for running GFS2 filesystems: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_high_availability_clusters/assembly_configuring-gfs2-in-a-cluster-configuring-and-managing-high-availability-clusters It would be very helpful to get both the missing packages from Resilient Storage into CentOS - particularly as they both apparently are being built already |
|
|
Is this a larger problem then in that CentOS is only providing *some* channels? Are there others besides Resilient Storage that need to be published as well? |
|
|
@jdshewey - an interesting question, but out of scope for this exact issue. (trying to keep it on point here) @JohnnyHughes - I opened Red Hat case #02615186 to bring attention to this issue, and have been informed (verbatim cut/paste): "I have seen that "JohnnyHughes" had replied you in the CentOS bug that, this package was not part of RHEL so they can include it in CentOS. So you might be able to mention there that this package is infact part of a RedHat repository and then CentOS members should be able to take a look into it again possibly." I would like to therefore request the CentOS packaging/build team re-examine the missing DLM package and inject it into the repositories, it is not encumbered by the vendor. |
|
|
I'm in the same situation as @troyengel, i would need `dlm` for setting up a cluster with `lvmlockd`. This is effectively impossible using CentOS 8, except by building the package from source (which i think should not be done for a long running deployment as it might make future updates more difficult). @ JohnnyHughes Are there any news on why the package is currently not included? As far as @troyengel said, RedHat stated that the package indeed is in RHEL, and it also seems that it is also built by koji[1], which makes me not understand why it would be missing in the first place. Since this also prevents a rather common use case for CentOS (as far as i see it though), deploying a cluster which typically need shared storage, i feel intrigued to ask why this issue has such a low priority? [1] https://koji.mbox.centos.org/koji/buildinfo?buildID=4801 |
|
|
I agree with @them's comment. But since I am just a consumer without contributing efforts at all. I can only wish this ticket has higher priority |
- Anonymous
