https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-6677 Lustre <p>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.</p> <p>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:</p> <ol> <li>Lustre must use some modern form of the kmod packaging standard to package its kernel modules</li> <li>Lustre must build with weak modules support</li> </ol> LU-6677

Package lustre correctly for Fedora/RHEL

Task Minor Closed Done Minh Diep Christopher Morrone llnl Tue, 2 Jun 2015 22:15:48 +0000 Fri, 22 Jul 2016 19:43:17 +0000 Fri, 22 Jul 2016 19:43:17 +0000 0 11 <p>Christopher J. Morrone (morrone2@llnl.gov) uploaded a new patch: <a href="http://review.whamcloud.com/15112" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/15112</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6677" title="Package lustre correctly for Fedora/RHEL" class="issue-link" data-issue-key="LU-6677"><del>LU-6677</del></a> build: Fix ldiskfs source autodetect for CentOS 6<br/> Project: fs/lustre-release<br/> Branch: b2_5<br/> Current Patch Set: 1<br/> Commit: 16cb264ca5cd959d01c22fc1e50e260e81f7f3e8</p> <p>Christopher J. Morrone (morrone2@llnl.gov) uploaded a new patch: <a href="http://review.whamcloud.com/15113" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/15113</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-6677" title="Package lustre correctly for Fedora/RHEL" class="issue-link" data-issue-key="LU-6677"><del>LU-6677</del></a> build: Add RHEL style kmod packages<br/> Project: fs/lustre-release<br/> Branch: b2_5<br/> Current Patch Set: 1<br/> Commit: e7238a49644dd7a5d30877b97bfb6dceb369e876</p> <p>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.</p> <p>Change <a href="http://review.whamcloud.com/15113" class="external-link" target="_blank" rel="nofollow noopener">15113</a> is the significant one. I recommend reading the Brian's commit comment, because it is pretty detailed about what the changes buy us.</p> <p>Minh is looking into this</p> <p>Another requirement for Lustre to be claimed "correctly packaged":</p> <ul> <li>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.</li> </ul> <p>My first question about using Koji is, does it support Suse, Ubuntu..and other distro?</p> <p>Koji does not support debian package format so no Ubuntu.</p> <p>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.</p> <p>Have we looked into OpenBuildService?</p> <p>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 <em>mock</em> when building packages for Fedora/RHEL/CentOS flavors of Linux distributions. The lbuild method of using rpm2cpio will almost certainly not be sufficient.</p> <p>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...</p> <p>Any further pointers and clarification are much appreciated.</p> <p>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.</p> <p>Hi Chris,</p> <p>Have you had a chance to look at <a href="http://review.whamcloud.com/#/c/12063/?" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/12063/?</a></p> <p>No, I have not.</p> <p>What are you thoughts on the approach versus how Brian Behlendorf's patch does it?</p> <p>I could be wrong but both approaches are very similar. I tend to like the approach that uses a single spec file. <br/> 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.</p> <p>If there's a way to do without installing kernel-devel on the build node, it would be great. </p> <p>Hi Chris,</p> <p>Is there anything else we need to do on this ticket? it seems like this is a dup of <a href="https://jira.whamcloud.com/browse/LU-5614" title="use %kernel_module_package for weak-updates" class="issue-link" data-issue-key="LU-5614"><del>LU-5614</del></a></p> <p><a href="https://jira.whamcloud.com/browse/LU-5614" title="use %kernel_module_package for weak-updates" class="issue-link" data-issue-key="LU-5614"><del>LU-5614</del></a> was only one of the components necessary. But yes, I think things are complete enough now to close this.</p> Related LU-5614 LU-3957 LU-3953 Development End date Tue, 15 Sep 2015 22:15:48 +0000 Rank 1|hzxerz: Rank (Obsolete) 9223372036854775807 Start date Tue, 2 Jun 2015 22:15:48 +0000