On Jun 24, 2005, at 2:01 AM, Bernard Li wrote:
I think for the first pass, I will just assume that the user will only
install _one_ resource manager and that will be the one being used.
Here's the code snippet from my modified test_cluster script:
if ( ($rm eq "OpenPBS") || ($rm eq "TORQUE") ) {
@ufiles = qw(testprint ssh_user_tests pbs_test test_cluster);
} else {
@ufiles = qw(testprint ssh_user_tests test_cluster);
}
Basically, it checks to see if the Resource Manager is either TORQUE
or OpenPBS, if so, then add pbs_test to the list of tests, otherwise
omit it.
If we add support for SGE, we will need to write a new script called
sge_test, and add one more condition to this code.
Should we take out pbs_test and put it inside the RM_Detect
Framework? I assume how we test stuff will change also, once we start
using APItest for more packages.
'zactly -- I would abstract the invocation of testing into the
RM_Detect framework altogether. You're right that it's generally a bad
idea to check which module you got -- you just want to get a component
(any component) and then invoke the methods on it. If you find
yourself writing conditional logic based on which component was
selected, you're probably thinking about it wrong.
So you might want a method such as run_test() on the components where
you can give the package root directory, or something like that. It'll
then run the test (if it exists) and return success or failure (perhaps
returning success if there is no test, or perhaps you can have a
separate method for checking to see if there is a test -- you get the
idea).
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
