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-11824 Lustre <p>The inclusion of LNDs in the kmod-lustre package can bring dependencies on other packages. For example, if the o2ib LND was built against Mellanox OFED, installing the kmod-lustre package will require the installation of the Mellanox OFED kernel modules.</p> <p>In some cases, it might be practical to install the same build of lustre packages on different nodes which would have different requirements (some nodes would have only Ethernet while others would have OPA or IB). The current packaging forces one to install the Mellanox OFED packages on the nodes which do not actually have IB hardware.</p> <p>In order to better control the dependencies required to be installed, an option at build time could allow to put the LND(s) bringing external dependencies in separate packages.</p> <p>The admin would then be free to decide which LNDs need to be installed on each type of node.</p> LU-11824

Have an option to build separate packages for lnds

Improvement Minor Open Unresolved Sebastien Piechurski Sebastien Piechurski Sun, 23 Dec 2018 16:52:25 +0000 Fri, 29 Oct 2021 20:06:32 +0000 Lustre 2.16.0 0 8 <p>Sebastien</p> <p>Is this something that you are going to work on or is this just a suggestion for something for someone else to work on?</p> <p>Peter</p> <p>If I understand right you want separate LNet packages for different types of interface configurations supplied by whamcloud. The main blocker to making this a reality is lctl which supplies the ability to collect debug logs. This in turn pulls in the entire lustre utilities software stack. To do this right lnetctl would need to handle debugging.</p> <p>Sebastien Piechurski (sebastien.piechurski@atos.net) uploaded a new patch: <a href="https://review.whamcloud.com/33911" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33911</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11824" title="Have an option to build separate packages for lnds" class="issue-link" data-issue-key="LU-11824">LU-11824</a> build: Optionally package LNDs in their own RPM<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 16b10ab75d83987a3695c69cb37461a18f77b363</p> <p>Hi James,</p> <p>Actually my goal here is only to get rid of the installation of external dependencies (like Mellanox OFED) on nodes which do not require it, but still make use of a single distribution of packages, in a modular way.</p> <p>Do you still see a problem with lctl and/or lnetctl if one LND that was built is actually not installed ?</p> <p>ok. <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=ashehata" class="user-hover" rel="ashehata">ashehata</a> can you comment on this when you are back in the office in the new year?</p> <p>Peter Jones: it would seem there was an issue with Jenkins at the time I submitted my patch.</p> <p>Is there a way I can have it re-evaluate my submission, or do I have to create a new patchset for it to evaluate again ?</p> <p>Sebastien,</p> <p>Someone from Whamcloud can re-trigger the build, or you can push an updated version of the patch.  Rebasing works if there's a newer version to rebase on to.  (But there isn't for this since you just pushed it)</p> <p>On trick to avoid waiting is to make a minor style fix or change and re-push the patch.</p> <p>In this case, I'm going to suggest a minor style change anyway, so you could change for that and re-push.</p> <p>My latest patchsets Maloo testing keeps falling in other bugs.</p> <p>As my patch does not actually touch running code, but only build code, is this eligible to the "trivial" Test-parameters ?</p> <p>Yes it is but, as an aside, you could also get the ability to re-trigger tests if need be. It is best to email directly about organizing that rather than posting in a JIRA ticket though.</p> Development Rank 1|i008nb: Rank (Obsolete) 9223372036854775807