Bug 447769

Summary: HTS does not allow manual scheduling of device-independant tests
Product: [Retired] Red Hat Hardware Certification Program Reporter: Greg Nichols <gnichols>
Component: Test Suite (harness)Assignee: Greg Nichols <gnichols>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 5CC: rlandry, ykun
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-24 18:09:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
hts/hardwaretest.py patch to change plan --add command
none
hts/test.py patch to change Test.getDevice to return None if no device none

Description Greg Nichols 2008-05-21 18:09:47 UTC
Description of problem:

HTS does not allow manual scheduling of device-independant tests, such as cpu
scaling, giving an error that --device or --udi options are required.

Workaround:

Supply a bogus device name via --device

Version-Release number of selected component (if applicable):

HTS 5.2 R13

Comment 1 Greg Nichols 2008-08-22 18:50:10 UTC
The following patch removes code that requires either --udi or --device to add a test, and replaces it with a warning and a prompt to confirm.

Comment 2 Greg Nichols 2008-08-22 18:51:25 UTC
Created attachment 314830 [details]
hts/hardwaretest.py patch to change plan --add command

Comment 3 Greg Nichols 2008-08-22 18:52:38 UTC
Created attachment 314831 [details]
hts/test.py patch to change Test.getDevice to return None if no device

Comment 4 Rob Landry 2008-08-26 14:12:40 UTC
It looks like this will allow more broken tests planning than it fixes cleanly planning for tests which don't require a device; unless I've missed where the test can say that it does or doesn't require a device?

Comment 5 Greg Nichols 2008-08-27 02:10:10 UTC
It is a manual override, and will allow tests to be scheduled that will fail for lack of a device.

An alternative would be to implement a mechanism where tests could specify whether or not they require a device, so that the "hts plan -add" code could refuse to add a test if a device was required, and not supplied.  Note that even with this new mechanism, the user could supply an inappropriate device.

For example: 

    hts plan --add --test storage --device eth0

In summary, "hts plan --add" is a manual override provided to work around 
automatic test planning failures.  There's no way for HTS 
prevent user error when supplying a device (or not supplying one),
since it's already failed.

Comment 6 Rob Landry 2008-08-27 21:50:07 UTC
We're probably best off implementing the feature where tests would require some # of params.  Using the network test as an example, --device won't quite cut it you also need a server.  Lots of effort might go into that depending on the number and types of params (ATM I believe there's only device and storage); an alternate way to look at this might be to consider if it is ever proper for a test not to require a device?

Comment 7 Greg Nichols 2008-08-28 01:22:49 UTC
  The network test already checks to see that --server is set to a system running the HTS server.

  Current code requires a device be supplied (either --device or --udi).   The 
validity of the device is not checked, since implementing such a check would make the command useless as a work-around.   For example, if HTS fails to schedule a test on a storage device, then later checks during the manual addition of a storage test would fail as well.    

  The current code does check if the supplied device is found, but only Warns if it can't find the device, and makes no attempt to see if the device is valid for the test being added.

- With this patch, if the user adds a test that requires a device, and fails to supply one (again, via --device or --udi), the test will fail, leaving the user no worse of than before, since manual addition of tests is a work-around for a different failure.

- the only real benefit to the inclusion of this patch is to fix the situation that has arisen where we've had to recommend users add bogus devices to get a test to manually scheduled - most recently cases were bugs where the usb test was not scheduled.   If this benefit is seen as incomplete, I'd recommend we simply not address this bug (WILL NOT FIX).  We'd be better served by improvements to HTS test planning so this kind of work-around isn't needed.

Comment 8 Rob Landry 2008-08-28 18:54:24 UTC
ok, for now we can take this as close enough, we are slightly better off (in not needing to provide bugus hardware options) but that better creates new issues (eg. more paramete validation the suite should be doing) which we can consider adding as later feature.