* Is it reasonable to build lvmlockd in this way?
@ 2017-05-10 9:10 Eric Ren
2017-05-10 16:37 ` David Teigland
0 siblings, 1 reply; 5+ messages in thread
From: Eric Ren @ 2017-05-10 9:10 UTC (permalink / raw)
To: lvm-devel
Hi David,
Firstly, I really appreciate your work on lvmlockd feature. I've enabled it for openSUSE,
and have testing on it, which works great.
But, we got a build problem on lvmlockd discussed here:
https://bugzilla.suse.com/show_bug.cgi?id=1037309
This is caused by the way openSUSE tries to build cluster-relative packages separately
by splitting spec file into different ones, in order to avoid dependencies when building
basic lvm packages:
https://build.opensuse.org/package/show/Base:System/lvm2
For cLVM, we can do it this way without problems. But, it cannot work for lvmlockd in this way,
because main lvm tools(like vgcreate) will link to the empty version of lvmlockd functions
(lockd_running_lock_type in lvmlockd.h).
Our package team insists that we should change lvmlockd to the clvm way so that we can
build lvmlockd separately. Before doing useless work, I really like to hear your advice first.
Any comments would be appreciated!
Regards,
Eric
^ permalink raw reply [flat|nested] 5+ messages in thread* Is it reasonable to build lvmlockd in this way? 2017-05-10 9:10 Is it reasonable to build lvmlockd in this way? Eric Ren @ 2017-05-10 16:37 ` David Teigland 2017-05-11 2:21 ` Eric Ren 0 siblings, 1 reply; 5+ messages in thread From: David Teigland @ 2017-05-10 16:37 UTC (permalink / raw) To: lvm-devel On Wed, May 10, 2017 at 05:10:27PM +0800, Eric Ren wrote: > Hi David, > > Firstly, I really appreciate your work on lvmlockd feature. I've enabled it for openSUSE, > and have testing on it, which works great. > > But, we got a build problem on lvmlockd discussed here: > https://bugzilla.suse.com/show_bug.cgi?id=1037309 > > This is caused by the way openSUSE tries to build cluster-relative packages separately > by splitting spec file into different ones, in order to avoid dependencies when building > basic lvm packages: > https://build.opensuse.org/package/show/Base:System/lvm2 > > For cLVM, we can do it this way without problems. But, it cannot work for lvmlockd in this way, > because main lvm tools(like vgcreate) will link to the empty version of lvmlockd functions > (lockd_running_lock_type in lvmlockd.h). > > Our package team insists that we should change lvmlockd to the clvm way so that we can > build lvmlockd separately. Before doing useless work, I really like to hear your advice first. > > Any comments would be appreciated! Hi, I'm a little out of my depth with build/packaging/distribution issues. First, I think you need to build with --enable-lvmlockd-dlm|sanlock, and provide the necessary bits of sanlock/dlm for building (the -devel subpackages of dlm and sanlock.) It sounds like there's some aversion to doing this, but I don't see the problem. Once it's built, we're putting the lvmlockd binary into a separate lvm2-lockd subpackage. When built with lvmlockd support, lvm will still operate fine without lvmlockd present, it will just report an error if you try to use it. I think this is what some of your references suggest. I can understand wanting to avoid including lvmlockd/dlm/sanlock everywhere that lvm itself is needed, but putting lvmlockd into a separate package should avoid that. Dave ^ permalink raw reply [flat|nested] 5+ messages in thread
* Is it reasonable to build lvmlockd in this way? 2017-05-10 16:37 ` David Teigland @ 2017-05-11 2:21 ` Eric Ren 2017-05-11 14:53 ` David Teigland 0 siblings, 1 reply; 5+ messages in thread From: Eric Ren @ 2017-05-11 2:21 UTC (permalink / raw) To: lvm-devel Hi! On 05/11/2017 12:37 AM, David Teigland wrote: > On Wed, May 10, 2017 at 05:10:27PM +0800, Eric Ren wrote: >> Hi David, >> >> Firstly, I really appreciate your work on lvmlockd feature. I've enabled it for openSUSE, >> and have testing on it, which works great. >> >> But, we got a build problem on lvmlockd discussed here: >> https://bugzilla.suse.com/show_bug.cgi?id=1037309 >> >> This is caused by the way openSUSE tries to build cluster-relative packages separately >> by splitting spec file into different ones, in order to avoid dependencies when building >> basic lvm packages: >> https://build.opensuse.org/package/show/Base:System/lvm2 >> >> For cLVM, we can do it this way without problems. But, it cannot work for lvmlockd in this way, >> because main lvm tools(like vgcreate) will link to the empty version of lvmlockd functions >> (lockd_running_lock_type in lvmlockd.h). >> >> Our package team insists that we should change lvmlockd to the clvm way so that we can >> build lvmlockd separately. Before doing useless work, I really like to hear your advice first. >> >> Any comments would be appreciated! > Hi, I'm a little out of my depth with build/packaging/distribution issues. > First, I think you need to build with --enable-lvmlockd-dlm|sanlock, and > provide the necessary bits of sanlock/dlm for building (the -devel > subpackages of dlm and sanlock.) It sounds like there's some aversion to > doing this, but I don't see the problem. Sorry, I didn't make the problem clear. Yes, it worked well when lvm and lvmlockd were built together. The problem came up when our package team want to avoid dependencies on cluster-relative devel packages at *building time*. They split lvm2.spec into 3 spec files: lvm2.spec[1], lvm2-clvm.spec[2] and device-mapper.spec[3]: [1] https://build.opensuse.org/package/view_file/Base:System/lvm2/lvm2.spec?expand=1 [2] https://build.opensuse.org/package/view_file/Base:System/lvm2/lvm2-clvm.spec?expand=1 [3] https://build.opensuse.org/package/view_file/Base:System/lvm2/device-mapper.spec?expand=1 So, lvm tools are built in lvm2.spec without "BuildRequires" on clustering devels like corosync, dlm, sanlock, while lvmlockd is built in lvm2-clvm.spec with all clustering things. As a result, lvm tools will pull in the empty functions in lvmlockd.h [4] because "LVMLOCKD_SUPPORT" is not defined. [4] https://sourceware.org/git/?p=lvm2.git;a=blob;f=lib/locking/lvmlockd.h;h=8b282d8c698a2b3cc18c81b4c152dc7d0b9e3e9b;hb=HEAD#l98 So every command using functions in lvmlockd.h will fail, even though wdmd, sanlock, lvmlockd are all ready. For example: tw1:~ # vgcreate --shared vgtest /dev/vdb Using a shared lock type requires lvmlockd. Failed to detect a running lock manager to select lock type. lockd_running_lock_type() is inlined the empty version into lvm tool in this case. I know it's tricky to build lvmlockd in the way above. But, they ask me: since lvm tools and cLVM can build this way, and run without problem, is it possible that lvm tools can be built without linking to lvmlockd functions? > > Once it's built, we're putting the lvmlockd binary into a separate > lvm2-lockd subpackage. When built with lvmlockd support, lvm will still Yes, we do the same. > operate fine without lvmlockd present, it will just report an error if you > try to use it. I think this is what some of your references suggest. I > can understand wanting to avoid including lvmlockd/dlm/sanlock everywhere > that lvm itself is needed, but putting lvmlockd into a separate package > should avoid that. Yes. But, our package team also want to reduce the dependencies when *building* basic lvm2 RPM. Do you think it's something feasible? Regards, Eric > > Dave > > -- > lvm-devel mailing list > lvm-devel at redhat.com > https://www.redhat.com/mailman/listinfo/lvm-devel > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Is it reasonable to build lvmlockd in this way? 2017-05-11 2:21 ` Eric Ren @ 2017-05-11 14:53 ` David Teigland 2017-05-12 5:05 ` Eric Ren 0 siblings, 1 reply; 5+ messages in thread From: David Teigland @ 2017-05-11 14:53 UTC (permalink / raw) To: lvm-devel On Thu, May 11, 2017 at 10:21:06AM +0800, Eric Ren wrote: > Hi! > > On 05/11/2017 12:37 AM, David Teigland wrote: > > On Wed, May 10, 2017 at 05:10:27PM +0800, Eric Ren wrote: > > > Hi David, > > > > > > Firstly, I really appreciate your work on lvmlockd feature. I've enabled it for openSUSE, > > > and have testing on it, which works great. > > > > > > But, we got a build problem on lvmlockd discussed here: > > > https://bugzilla.suse.com/show_bug.cgi?id=1037309 > > > > > > This is caused by the way openSUSE tries to build cluster-relative packages separately > > > by splitting spec file into different ones, in order to avoid dependencies when building > > > basic lvm packages: > > > https://build.opensuse.org/package/show/Base:System/lvm2 > > > > > > For cLVM, we can do it this way without problems. But, it cannot work for lvmlockd in this way, > > > because main lvm tools(like vgcreate) will link to the empty version of lvmlockd functions > > > (lockd_running_lock_type in lvmlockd.h). > > > > > > Our package team insists that we should change lvmlockd to the clvm way so that we can > > > build lvmlockd separately. Before doing useless work, I really like to hear your advice first. > > > > > > Any comments would be appreciated! > > Hi, I'm a little out of my depth with build/packaging/distribution issues. > > First, I think you need to build with --enable-lvmlockd-dlm|sanlock, and > > provide the necessary bits of sanlock/dlm for building (the -devel > > subpackages of dlm and sanlock.) It sounds like there's some aversion to > > doing this, but I don't see the problem. > Sorry, I didn't make the problem clear. Yes, it worked well when lvm and > lvmlockd were built together. > The problem came up when our package team want to avoid dependencies on > cluster-relative devel packages > at *building time*. They split lvm2.spec into 3 spec files: lvm2.spec[1], > lvm2-clvm.spec[2] and device-mapper.spec[3]: That doesn't sound like a terrible problem. > [1] https://build.opensuse.org/package/view_file/Base:System/lvm2/lvm2.spec?expand=1 > [2] https://build.opensuse.org/package/view_file/Base:System/lvm2/lvm2-clvm.spec?expand=1 > [3] https://build.opensuse.org/package/view_file/Base:System/lvm2/device-mapper.spec?expand=1 > > So, lvm tools are built in lvm2.spec without "BuildRequires" on clustering > devels like corosync, dlm, sanlock, > while lvmlockd is built in lvm2-clvm.spec with all clustering things. > > As a result, lvm tools will pull in the empty functions in lvmlockd.h [4] > because "LVMLOCKD_SUPPORT" is not defined. > > [4] https://sourceware.org/git/?p=lvm2.git;a=blob;f=lib/locking/lvmlockd.h;h=8b282d8c698a2b3cc18c81b4c152dc7d0b9e3e9b;hb=HEAD#l98 > > So every command using functions in lvmlockd.h will fail, even though wdmd, > sanlock, lvmlockd are all ready. For example: > > tw1:~ # vgcreate --shared vgtest /dev/vdb > Using a shared lock type requires lvmlockd. > Failed to detect a running lock manager to select lock type. > > lockd_running_lock_type() is inlined the empty version into lvm tool in this case. > > I know it's tricky to build lvmlockd in the way above. But, they ask me: > since lvm tools and cLVM can build this way, and run without problem, is it > possible that lvm tools can be built without linking to lvmlockd functions? I think they have it backward: clvm should have been done like lvmlockd. clvm apparently requires them to build lvm *twice*, with/without clvm, and the one built without cannot be used with. For lvmlockd they can simply build lvm once and use that one with or without lvmlockd. That's much better. If they really want to build lvm twice, once without sanlock/dlm devel packages around, and once with the devel packages, and then they want to run the lvm binary from the first build with or without the lvmlockd binary from the second build... that's comical but probably simple to do. You would enable lvmlockd in configure of both builds, but skip compiling the daemons/lvmlockd directory the first time, i.e. apply this patch the first time you build, and drop it for the second build: diff --git a/daemons/Makefile.in b/daemons/Makefile.in index ebbd740efa9c..f5e815839979 100644 --- a/daemons/Makefile.in +++ b/daemons/Makefile.in @@ -40,9 +40,9 @@ ifeq ("@BUILD_LVMPOLLD@", "yes") SUBDIRS += lvmpolld endif -ifeq ("@BUILD_LVMLOCKD@", "yes") - SUBDIRS += lvmlockd -endif +# ifeq ("@BUILD_LVMLOCKD@", "yes") +# SUBDIRS += lvmlockd +# endif ifeq ("@BUILD_LVMDBUSD@", "yes") SUBDIRS += lvmdbusd ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Is it reasonable to build lvmlockd in this way? 2017-05-11 14:53 ` David Teigland @ 2017-05-12 5:05 ` Eric Ren 0 siblings, 0 replies; 5+ messages in thread From: Eric Ren @ 2017-05-12 5:05 UTC (permalink / raw) To: lvm-devel Hi David! On 05/11/2017 10:53 PM, David Teigland wrote: > On Thu, May 11, 2017 at 10:21:06AM +0800, Eric Ren wrote: > [...snip...] >> Sorry, I didn't make the problem clear. Yes, it worked well when lvm and >> lvmlockd were built together. >> The problem came up when our package team want to avoid dependencies on >> cluster-relative devel packages >> at *building time*. They split lvm2.spec into 3 spec files: lvm2.spec[1], >> lvm2-clvm.spec[2] and device-mapper.spec[3]: > That doesn't sound like a terrible problem. Yes. > >> [1] https://build.opensuse.org/package/view_file/Base:System/lvm2/lvm2.spec?expand=1 >> [2] https://build.opensuse.org/package/view_file/Base:System/lvm2/lvm2-clvm.spec?expand=1 >> [3] https://build.opensuse.org/package/view_file/Base:System/lvm2/device-mapper.spec?expand=1 >> >> So, lvm tools are built in lvm2.spec without "BuildRequires" on clustering >> devels like corosync, dlm, sanlock, >> while lvmlockd is built in lvm2-clvm.spec with all clustering things. >> >> As a result, lvm tools will pull in the empty functions in lvmlockd.h [4] >> because "LVMLOCKD_SUPPORT" is not defined. >> >> [4] https://sourceware.org/git/?p=lvm2.git;a=blob;f=lib/locking/lvmlockd.h;h=8b282d8c698a2b3cc18c81b4c152dc7d0b9e3e9b;hb=HEAD#l98 >> >> So every command using functions in lvmlockd.h will fail, even though wdmd, >> sanlock, lvmlockd are all ready. For example: >> >> tw1:~ # vgcreate --shared vgtest /dev/vdb >> Using a shared lock type requires lvmlockd. >> Failed to detect a running lock manager to select lock type. >> >> lockd_running_lock_type() is inlined the empty version into lvm tool in this case. >> >> I know it's tricky to build lvmlockd in the way above. But, they ask me: >> since lvm tools and cLVM can build this way, and run without problem, is it >> possible that lvm tools can be built without linking to lvmlockd functions? > I think they have it backward: clvm should have been done like lvmlockd. > clvm apparently requires them to build lvm *twice*, with/without clvm, and > the one built without cannot be used with. For lvmlockd they can simply > build lvm once and use that one with or without lvmlockd. That's much > better. Got it! > > If they really want to build lvm twice, once without sanlock/dlm devel > packages around, and once with the devel packages, and then they want to > run the lvm binary from the first build with or without the lvmlockd > binary from the second build... that's comical but probably simple to do. > You would enable lvmlockd in configure of both builds, but skip compiling > the daemons/lvmlockd directory the first time, i.e. apply this patch the > first time you build, and drop it for the second build: Thanks very much for your generous help! Regards, Eric > > diff --git a/daemons/Makefile.in b/daemons/Makefile.in > index ebbd740efa9c..f5e815839979 100644 > --- a/daemons/Makefile.in > +++ b/daemons/Makefile.in > @@ -40,9 +40,9 @@ ifeq ("@BUILD_LVMPOLLD@", "yes") > SUBDIRS += lvmpolld > endif > > -ifeq ("@BUILD_LVMLOCKD@", "yes") > - SUBDIRS += lvmlockd > -endif > +# ifeq ("@BUILD_LVMLOCKD@", "yes") > +# SUBDIRS += lvmlockd > +# endif > > ifeq ("@BUILD_LVMDBUSD@", "yes") > SUBDIRS += lvmdbusd > > -- > lvm-devel mailing list > lvm-devel at redhat.com > https://www.redhat.com/mailman/listinfo/lvm-devel > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-05-12 5:05 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-05-10 9:10 Is it reasonable to build lvmlockd in this way? Eric Ren 2017-05-10 16:37 ` David Teigland 2017-05-11 2:21 ` Eric Ren 2017-05-11 14:53 ` David Teigland 2017-05-12 5:05 ` Eric Ren
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.