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: | 5 | CC: | 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
Greg Nichols
2008-05-21 18:09:47 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. Created attachment 314830 [details]
hts/hardwaretest.py patch to change plan --add command
Created attachment 314831 [details]
hts/test.py patch to change Test.getDevice to return None if no device
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? 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. 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? 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. 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. |