[LU-2229] Lustre configure requires zfs/spl on the host node rather than as part of the build environment. Created: 15/Feb/12 Updated: 09/Jan/20 Resolved: 09/Jan/20 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Chris Gearing (Inactive) | Assignee: | Brian Behlendorf |
| Resolution: | Low Priority | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 2893 | ||||||||
| Description |
|
When configure for lustre runs it decides the availability of spl/zfs by looking at the host node rather than looking at the build environment. This means that the build node has to have spl/zfs installed even though the actually building of lustre-zfs uses the build environment which has a spl/zfs development environment available. I don't think this make sense, it should not be a requirement for the build host to have every feature installed that the target build is going to contain. This has caused problems here; TT-391; when our build nodes where upgraded. |
| Comments |
| Comment by Brian Murrell (Inactive) [ 15/Feb/12 ] |
|
The proper way to achieve this is to have lbuild build zfs/spl and then use rpm2cpio to unpack the -devel packages and then point configure at them such as is done for the kernel and ofed, as two examples. This is how the original code I wrote for lbuild to do zfs/spl building did it. I recall there is a patch around for doing this zfs/spl build. Is it still undergoing review or has it landed somewhere? |
| Comment by Brian Behlendorf [ 28/Jun/13 ] |
|
The following two patches were merged in to the spl/zfs code. They should allow for installation of the devel packages in to arbitrary buildroots. Although I'd argue this could have been handled using a standard build tool such as mock. https://github.com/zfsonlinux/spl/commit/485b471eb29cfa3a6dbac7de8fda5e020068044a |
| Comment by Christopher Morrone [ 06/Sep/13 ] |
I could not really disagree more with this approach. This is a dirty hack to avoid proper rpm building procedures, and should not be encouraged. |
| Comment by Brian Murrell (Inactive) [ 07/Sep/13 ] |
I suppose this is another jab at the lack of the use of something like mock in the Intel build farm. In an ideal world, yes, we would (at least investigate) completely overhaul(ing) the build farm to use something like mock (TEI-532) for rpm building. But that's a project which, AFAIK, has not been scoped and prioritized. So given that, we have to work within the boundaries of what is possible to fix this problem today. That is the context in which my suggestion of unpacking the -devel rpm should be taken. This is no different than how any of the other -devel rpms are utilized by configure so this is not a new "dirty hack" but just another instance of a series of existing hacks to be able to build lustre in a "mock-less" build environment without having to be root to install and remove rpms during the build. |
| Comment by James A Simmons [ 09/Sep/13 ] |
|
Does |
| Comment by Andreas Dilger [ 09/Jan/20 ] |
|
Close old bug |