(→Locate and breakdown the problem) |
(→Usage) |
||
| Line 66: | Line 66: | ||
== Usage == | == Usage == | ||
| - | If there is a problem in running your test(s). Then once again the logs are a good place to start | + | If there is a problem in running your test(s). Then once again the logs are a good place to start of which the http logger is the most user friendly. The Exception and traceback should give an indication of the problem. Check what any [http://wiki.meego.com/Quality/QA-tools/OTS/ErrorCodes error code] means that might give you a clue. |
== FAQs == | == FAQs == | ||
Contents |
This troubleshooting guide aims to help with OTS installation and usage.
Please remember that OTS is at a relatively early stage in its development and evolving rapidly and whilst every effort is made to keep all the documentation up-to-date there will be some inevitable time lag.
This section suggests how you can apply simple fault-finding techniques to OTS...
There are a number of ways to view the OTS testrun:
The Main OTS log is written here to /var/log/ots
This is configurable by the 'logging.conf' file in the root directory
The Worker can be configured to log to a file specified by the "log_file" parameter in the Worker config file.
In addition there is an Http Logger Plugin. FIXME wiki page?
OTS is a highly modular system. Most of the Components are designed to be run as tools in their own right. They have command line interfaces and can be run independently.
A basic understanding of the Architecture and the responsibilities of the Components should guide you through it.
There is generally documentation for each of the Components and illustrations on how the the individual tool is run. It is all Open Source, nothing is hidden!
Assuming you have installed the OTS component you can check the version as follows:
$python
>>> import ots.worker >>> ots.worker.__VERSION__ '0.8r0.0.1-338-gdbe7dev' >>>
Check the OTS bug tracker
If you have been following the Installation Instructions and still run into problems then you might benefit from the Developer Documentation. The Developer Documentation show how the Unit Tests and Component Tests are run. If the unittests or component tests are failing then the tracebacks should give an indication as to what the problems are.
If there is a problem in running your test(s). Then once again the logs are a good place to start of which the http logger is the most user friendly. The Exception and traceback should give an indication of the problem. Check what any error code means that might give you a clue.
If you are firing runs and they don't appear to be taken by the worker it is worth looking at the Queues. This service is provided by RabbitMQ and the rabbitmqctl tool is a useful aid.
Instructions for key authentication and dependent packages are all dealt with in this wiki
Flashing can work intermittently with some Architecture / Image combinations. It can also be a time consuming process so a certain degree of patience is required. There are some notes on flashing here that should help pinpoint the problem. Unfortunately there is always a chance that even if you have things set up correctly and it won't work first time - so try again.
Any hardware control operation that requires USB will require the permissions to be set appropriately.
e.g. By following these instructions for flashing you can avoid root access for the Flasher and all the dependent modules (Conductor and Worker)