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-1409 Lustre <p>If you load up the lustre-tests RPM, you would reasonably expect it<br/> to pull in any additional commands and libraries needed. Nope.<br/> After some toe stubbing and a little thinking, a few dependencies<br/> are obvious candidates:<br/> attr, acl, e2fsprogs, perl and pdsh<br/> A patch to do this will be posted as a review request "shortly".</p> UNIX LU-1409

The lustre-tests package needs more extensive dependencies

Bug Minor Resolved Won't Fix Cliff White Bruce Korb patch Tue, 15 May 2012 17:02:39 +0000 Fri, 19 Sep 2014 15:14:59 +0000 Fri, 19 Sep 2014 15:14:59 +0000 Lustre 2.5.0 0 4 <p>The lustre-tests RPM is intended to be installed on the client, and is intended to be able to install on as many different systems as possible.</p> <p>It shouldn't necessarily require ldiskfsprogs, since this is only needed on the server. If there are specific tests that require e2fsprogs commands, they should typically be using "do_facet" or similar to run on the server. Hmm, I guess sanity.sh test_37* does use a small loopback filesystems for testing block device and loopback files, but I wonder if these should use "skip_env" if mke2fs is not installed?</p> <p>Similarly, pdsh is optional since it is possible to configure $PDSH to point to other tools that can do remote operations (such as SSH). It is also possible to run "client only" tests that do not have any remote access, and many subtests are skipped if remote server access is not possible (either because of no pdsh, or because the tester does not want to allow access to the server without a password). That said, I don't think tests are run in this more on a regular basis.</p> <p>Perl usage was removed from master (in 2.2 commit 26bb579a) for the one test that I'm aware of that used it directly (sanityn.sh test_3), and I'm not aware of other tests that currently depend on it. There are a few scripts that do use perl (e.g. checkstack.pl, rename.pl, leak_finder.pl), but they do not run as part of any normal test. Since perl is pretty much ubiquitous, I don't think this is critical either way.</p> <p>There is a check in test_102a() for setfattr that avoids running tests that depend on them if they are not installed. It looks like this check is missing from some of the other test_102* subtests. Similarly, test_103() checks for getfacl before running the ACL tests.</p> <p>In general, I agree that we want to make the tests as easy to install and run as possible, but I also want to avoid dragging in too many dependencies that may make it harder to install the RPM and run the tests in the first place.</p> <p>"Pick your favorite poison."</p> <p>Perhaps jigger something to trap on "command not found" errors?<br/> Our testing guys were sufficiently frustrated that the bug report<br/> that landed on my desk was marked, "blocker". Perhaps an exaggeration <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/>.<br/> The automake way is to wrap all dubious tools inside a script wrapper<br/> named "missing". If the "missing" script finds the tool, it exec-s it.<br/> Something similar? Surely not today though. Maybe part of the testing<br/> rework.</p> <p>Meanwhile, folks here thought it really, really important to add these<br/> dependencies to the lustre-tests rpm. And we (you and I) agree that<br/> there are trade-offs. Can we (Whamcloud and Xyratex) agree on where<br/> to draw the line? <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/> Cheers - Bruce</p> <p><a href="http://review.whamcloud.com/2818" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/2818</a></p> <p><a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a> is also looking at fixing up the spec file.</p> <p>It is currently on hold and the residue of this patch should have no effect on that project anyway.<br/> Actually, that project does not explicitly state that comprehensibility is a goal. Comprehensibility<br/> is as important in a spec file as it is in a source file, so it needs to be a goal.</p> <p>Bruce is there a follow up to the first patch? Any new patch should be based on Master. </p> <p>Xyratex-bug-id: <a href="http://jira-nss.xy01.xyratex.com:8080/browse/MRP-488" class="external-link" target="_blank" rel="nofollow noopener">MRP-488</a></p> <p>Without an update I will close this LU at the end of the month. </p> <p>Please reopen if you decide to peruse this in the future. </p> <p>I notice that <a href="http://review.whamcloud.com/#change,2851" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,2851</a> was pushed into gerrit. Is this directly related to this original ticket or would it be more appropriate to track this under a new ticket?</p> <p>That change was strictly cleanup. Shell scripting going past column 168 gets me cross-eyed.</p> <p>Our testing folks are not still complaining, so I'm not being prodded to push another patch.<br/> Stillandall, it is inconvenient for a tester to run a test and wind up seeing some obscure<br/> failure instead of a clear message: you have not installed the "foo" package, so you<br/> cannot run this test. A good model for handling the issue is the "missing" wrapper script.<br/> Either that, or put in appropriate dependencies so that testing packages pull in what's needed.</p> <p>There is a new patch. </p> Development Rank 1|hzvrgn: Rank (Obsolete) 8340 Severity