[#LU-288] In tree single node testing uses installed lustre binaries by default, not in tree binaries.

[LU-288] In tree single node testing uses installed lustre binaries by default, not in tree binaries. Created: 06/May/11 Updated: 04/Jun/11 Resolved: 04/Jun/11
Status:	Resolved
Project:	Lustre
Component/s:	None
Affects Version/s:	Lustre 2.1.0
Fix Version/s:	Lustre 2.1.0

Type:

Improvement

Priority:

Minor

Reporter:

Prakash Surya (Inactive)

Assignee:

Zhenyu Xu

Resolution:

Fixed

Votes:

Labels:

None

Rank (Obsolete):

5003

Description

Not sure if this is done by design or not, but when running the single node test from within the lustre source tree the installed binaries are used by default; not the binaries in the lustre tree.

For example, running sanity.sh will pick up /usr/bin/lfs and use that binary if it exists (or another lfs found in $PATH I would assume) instead of $LUSTRE/lustre/utils/lfs.

Personally, I find this a bit confusing and frustrating at times. Say, I am working on the lfs command. If I make a change, recompile and run sanity.sh; this new patched version will not be used if there is a version that is already installed. It takes manual intervention to get the test to use my patched version (i.e. running 'export LFS=$LUSTRE/lustre/utils/lfs').

Is this by design?

Comments

Comment by Andreas Dilger [ 06/May/11 ]

It definitely makes sense to use the binaries from the current build tree, if the tests are being run from there. I prefer to do this by prepending the right path to $PATH, instead of forcing all scripts to explicitly specify the full pathname to each tool. Using PATH means all scripts will be fixed, while forcing a full path for every call means a lot of effort to fix the problem, and ongoing opportunity to break the testing if some new usage of "lfs" is in place of a fully-qualified "$LFS" or similar.

Of related interest is fixing bug 18057 (see https://bugzilla.lustre.org/show_bug.cgi?id=18057#c17), which is related to this. Testing from the build tree will overwrite /sbin/mount.lustre, which is usually not fatal, but is wrong and can cause testing to fail in some cases.

Comment by Prakash Surya (Inactive) [ 06/May/11 ]

I prefer to do this by prepending the right path to $PATH, instead of forcing all scripts to explicitly specify the full pathname to each tool.

Agreed. So essentially the code in test-framework.sh (and possibly elsewhere) could be changed from:

if ! echo $PATH | grep -q $LUSTRE/utils; then
        export PATH=$PATH:$LUSTRE/utils
fi

to:

if ! echo $PATH | grep -q $LUSTRE/utils; then
        export PATH=$LUSTRE/utils:$PATH
fi

Or am I missing something?

I think the shell's command lookup hash may have to be updated as well.

Comment by Peter Jones [ 09/May/11 ]

Bobijam

Could you please look into this one?

Thanks

Peter

Comment by Prakash Surya (Inactive) [ 09/May/11 ]

Of related interest is fixing bug 18057 (see https://bugzilla.lustre.org/show_bug.cgi?id=18057#c17), which is related to this. Testing from the build tree will overwrite /sbin/mount.lustre, which is usually not fatal, but is wrong and can cause testing to fail in some cases.

In our environment, we're booting diskless nodes and the rootfs is mounted readonly. So cp'ing mount.lustre acutally fails in that case. Thus, we have to have a version already installed to run the tests.

I can't seem to access bugzilla.lustre.org right now, but from what I remember from reading into it on Friday it seems the big hangup has to do with handling the '-o loop' option. Does it make sense to simply use the '--bind' mount option and mount the executable in /sbin? And then umount it after the test completes?

i.e.

# Rather than cp use the following..
mount --bind $LUSTRE/lustre/utils/mount.lustre /sbin/mount.lustre

# And unmount after tests are run
umount /sbin/mount.lustre

Although, I haven't done any real testing to see if this would actually work.

Comment by Zhenyu Xu [ 10/May/11 ]

tried the bind mount, and it works.

patch tracking at http://review.whamcloud.com/525