[LU-5903] make lbuild work without any command line arguments

• Status: Open
• Project: Lustre
• Type: Improvement
• Priority: Minor
• Reporter: Bob Glossman (Inactive)
• Assignee: WC Triage
• Resolution: Unresolved
• Labels: llnl

Description

After some discussion on Skype with Brian Murrell I'm entering this ticket for lbuild. Currently lbuild works well for reproducibly building kernel and lustre rpms in our Jenkins build environment. If it could be made to perform argument free it would be more useful for manual builds in other than Jenkins. This would have a number of advantages over other documented methods like those on our wiki pages:
1) a single line, simple command for building kernel and/or lustre rpms without a lot of manual, error prone steps.
2) rpm payloads from a manual build that would look a lot more like those from Jenkins builds. this is especially true of kernel rpms, where those generated by Jenkins builds look a lot more like distro based kernel rpms than those generated by current manual methods.
3) would provide a simple, standard, and repeatable way of doing manual builds so that we could move away from everybody doing them a little differently.

It would also be nice if lbuild could optionally keep around the patched kernel source tree after the build finishes instead of cleaning it all up and deleting it. Having the sources around for reference is an invaluable resource for many developers.

Brian advises "nothing comes to mind immediately about why that cannot work"

Comments

[Christopher Morrone]

I am going to vote a big thumbs down for this approach.

I agree that lbuild builds things in a weird way that is unlike what anyone else would do at the command line, or anywhere else. But the solution is not to make lbuild the One Tool To Rule Them All. Instead, you should put that effort into moving the Intel Jenkins build system in a direction that is more in line with what everyone else in the world does to build packages.

For the rpm builds, that means not dissembling the rpms with rpm2cpio/cpio. It also most likely means moving to a some kind of mock-based build system.

The more you focus on expanding the usage of lbuild's bizarre way of building things, the less exposure the core Intel Lustre team will have to the completely normal ways of building things that other people use. You'll break things for normal build patterns even more often than you currently do (quite often).

Please, just don't do it. We're already at our wits' end with the Lustre build system, and this is just going to take things further in the wrong direction.

[Andreas Dilger]

Two suggestions I've made about lbuild before and can make again here:

• lbuild could initially be used as the "make rpms" target even if it currently needs command-line args, since these can be supplied by the Makefile
• the default for "make rpms" should NOT be to build a kernel RPM each time (which takes ages), only the Lustre RPMs. There should be a separate Makefile target to build a kernel, like "make kernel" or similar

[Brian Behlendorf]

For whatever it's worth let me offer a few observations and my personal lessons learned based on my experience building kmods for ZFS.

• Avoid requiring a patched kernel unless there is absolutely no other way. This may mean finding an alternate way to accomplish something, adding additional configure checks, or just living without some functionality. But spending the time upfront to do this pays huge long term dividends. Allowing your developers to use stock kernels saves them time and it's what end users prefer. This also makes it far easier to keep current with the latest kernel.org releases.
• Providing a 'make rpms' target for the package is convenient but make sure to limit its scope to that package. Follow the principle of least astonishment (POLA) whenever possible. It would be surprising if the Lustre 'make rpms' target in anyway attempted to build something other than Lustre.
• Write the 'make rpms' target such that it is depends on the products of other common build targets. This ensures that all the build targets are commonly tested so you immediately notice a problem. For example, 'make rpms' could depend on 'make srpms' which in turn depends on 'make dist'.
• Whenever possible don't invent your own thing. I know it's fun. But odds are somebody has already solved your issue. Spend some time researching what other have done first.

[Brian Murrell (Inactive)]

adilger: Or turn it around so that lbuild uses make rpms for it's Lustre building part of the process rather than doing it's own thing. At least then make rpms gets regular testing and is known to produce the same thing that lbuild will produce as far as RPMs for Lustre itself.

behlendorf: Absolutely agreed about avoiding patching the kernel. That would remove the entire need to [re-]build a kernel in lbuild. But sadly, patching the kernel is still a requirement for Lustre. I'm not sure where we stand on eliminating that. adilger would have a much better idea on that than I. Also agreed on make {dist,srpms,rpms}. I think that's how it works already. Admittedly though it's been a while since I had my fingers in Lustre's Makefile though.

[Christopher Morrone]

Or turn it around so that lbuild uses make rpms for it's Lustre building part of the process rather than doing it's own thing.

Yes, that would make much more sense. lbuild is a high level script that builds many packages (e.g. Linux, Lustre, IB packages, ZFS.) It is part of the Intel automated build system, not part of the Lustre build system. That is why lbuild was relocated to the contrib subdirectory. Nothing in lbuild is necessary to build Lustre, and we should strive to keep it that way.

Lustre's internal build system calling out to lbuild would be a laying violation.

Also agreed on make

Unknown macro: {dist,srpms,rpms}

. I think that's how it works already.

Currently that is not the case. make srpm makes a source rpm. make rpm ignores make srpm's product entirely and goes ahead and rebuilds the source rpm in addition to building the binary rpms.

Livermore's 2.5.3-llnl branch has a patch that accomplishes that (see github.com/chaos/lustre). There are three patches on that branch labelled "LU-1199" that eventually could be pushed upstream again.

In the mean time, I created LU-5919 to track that issue. I also pushed a copy of the patch in question to gerrit. It is based on b2_5, but I won't have time to port it to master until after Supercomputing.