[LU-11824] Have an option to build separate packages for lnds

• Status: Open
• Project: Lustre
• Fix Version/s: Lustre 2.16.0
• Type: Improvement
• Priority: Minor
• Reporter: Sebastien Piechurski
• Assignee: Sebastien Piechurski
• Resolution: Unresolved

Description

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.

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.

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.

The admin would then be free to decide which LNDs need to be installed on each type of node.

Comments

[Peter Jones]

Sebastien

Is this something that you are going to work on or is this just a suggestion for something for someone else to work on?

Peter

[James A Simmons]

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.

[Gerrit Updater]

Sebastien Piechurski ([e-mail]) uploaded a new patch: https://review.whamcloud.com/33911
Subject: LU-11824 build: Optionally package LNDs in their own RPM
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 16b10ab75d83987a3695c69cb37461a18f77b363

[Sebastien Piechurski]

Hi James,

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.

Do you still see a problem with lctl and/or lnetctl if one LND that was built is actually not installed ?

[Peter Jones]

ok. ashehata can you comment on this when you are back in the office in the new year?

[Sebastien Piechurski]

Peter Jones: it would seem there was an issue with Jenkins at the time I submitted my patch.

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 ?

[Patrick Farrell (Inactive)]

Sebastien,

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)

On trick to avoid waiting is to make a minor style fix or change and re-push the patch.

In this case, I'm going to suggest a minor style change anyway, so you could change for that and re-push.

[Sebastien Piechurski]

My latest patchsets Maloo testing keeps falling in other bugs.

As my patch does not actually touch running code, but only build code, is this eligible to the "trivial" Test-parameters ?

[Peter Jones]

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.