[LU-6677] Package lustre correctly for Fedora/RHEL

• Status: Closed
• Project: Lustre
• Type: Task
• Priority: Minor
• Reporter: Christopher Morrone
• Assignee: Minh Diep
• Resolution: Done
• Labels: llnl

Description

LLNL will be moving to RHEL7 on new systems in the not-too-distant-future. As part of the move, we are also transitioning to a new rpm build farm based on the standard Fedora Koji build system.

We need Lustre to be correctly RPM packaged using modern RPM packaging best practices, and it needs to be buildable under Koji. Off the top of my head, there are two main initial things that need to change to meet that definition:

1. Lustre must use some modern form of the kmod packaging standard to package its kernel modules
2. Lustre must build with weak modules support

Issue Links

• is related to: LU-5614 use %kernel_module_package for weak-u...
• is related to: LU-3957 Create separate server and client bin...
• is related to: LU-3953 lustre build system improvments

Comments

[Gerrit Updater]

Christopher J. Morrone ([e-mail]) uploaded a new patch: http://review.whamcloud.com/15112
Subject: LU-6677 build: Fix ldiskfs source autodetect for CentOS 6
Project: fs/lustre-release
Branch: b2_5
Current Patch Set: 1
Commit: 16cb264ca5cd959d01c22fc1e50e260e81f7f3e8

[Gerrit Updater]

Christopher J. Morrone ([e-mail]) uploaded a new patch: http://review.whamcloud.com/15113
Subject: LU-6677 build: Add RHEL style kmod packages
Project: fs/lustre-release
Branch: b2_5
Current Patch Set: 1
Commit: e7238a49644dd7a5d30877b97bfb6dceb369e876

[Christopher Morrone]

I pushed two patches for b2_5 that were developed at LLNL by Brian Behledorf. He based them on our local LLNL 2.5 branch, and I just did a very naive rebase onto b2_5 so I could share them with the community. I didn't even check if they work on b2_5, but that isn't the point, since I know that b2_5 is no longer a live branch. I just want people to see the approach that Brian took. This could be the basis of a more complete solution.

Change 15113 is the significant one. I recommend reading the Brian's commit comment, because it is pretty detailed about what the changes buy us.

[Peter Jones]

Minh is looking into this

[Christopher Morrone]

Another requirement for Lustre to be claimed "correctly packaged":

• It must be possible to build lustre one time (all of lustre, including the server parts), but only install the client related packages on client nodes. Likewise it should be possible to only install server related packages from the same one build on server nodes.

[Minh Diep]

My first question about using Koji is, does it support Suse, Ubuntu..and other distro?

[James A Simmons]

Koji does not support debian package format so no Ubuntu.

[Minh Diep]

From what I read, Koji is similar to jenkins but it's limited to build RPMS and no Ubuntu. sounds like this is a set back.

[Minh Diep]

Have we looked into OpenBuildService?

[Christopher Morrone]

Just to be clear, I never implied that Koji could be a build system for anything other then Fedora and RHEL. The requirement is in this ticket is just that Lustre needs to build correctly under Koji and result in RPMs that meet modern rpm packaging best practices. At a minimum, I suspect that means that you'll need to use mock when building packages for Fedora/RHEL/CentOS flavors of Linux distributions. The lbuild method of using rpm2cpio will almost certainly not be sufficient.

[Minh Diep]

Thanks Chris for clarifying the intention. I completely agree with you that much work and time need to invest in lbuild (is anyone using this beside Intel build tools?) and makefiles, spec...

Any further pointers and clarification are much appreciated.

[Christopher Morrone]

Livermore isn't using lbuild, but I know that there were a couple of places that are, or were, using it. I moved lbuild into the contrib subdirectory, so there is already a big hint that lbuild is not part of the canonical build system. With that change, I would argue that we do not need to worry too much about how changing or replacing lbuild will impact users. It would not hurt, though, to give people warning on lustre.org mailing lists about changes that are coming in the build system so people can be prepared.

[Minh Diep]

Hi Chris,

Have you had a chance to look at http://review.whamcloud.com/#/c/12063/?

[Christopher Morrone]

No, I have not.

What are you thoughts on the approach versus how Brian Behlendorf's patch does it?

[Minh Diep]

I could be wrong but both approaches are very similar. I tend to like the approach that uses a single spec file.
Both will need some changes in the building infrastructure which need to install kernel-devel right on to the build node which is not too difficult to do.

If there's a way to do without installing kernel-devel on the build node, it would be great.

[Minh Diep]

Hi Chris,

Is there anything else we need to do on this ticket? it seems like this is a dup of LU-5614

[Christopher Morrone]

LU-5614 was only one of the components necessary. But yes, I think things are complete enough now to close this.