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

• Type: Task
• Resolution: Done
• Priority: Minor
• Labels: llnl
• Assignee: Minh Diep
• Reporter: Christopher Morrone (Inactive)

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-updates
• is related to: LU-3957 Create separate server and client binary rpms from one build
• is related to: LU-3953 lustre build system improvments

Comments

[Christopher Morrone (Inactive)]

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

[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

[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.

[Christopher Morrone (Inactive)]

No, I have not.

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

[Minh Diep]

Hi Chris,

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

[Christopher Morrone (Inactive)]

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]

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.