virt: Make virsh absence non fatal for other tests

This is a solution for issue #563.

If one is only testing kvm components, for example,
the absence of virsh should not be relevant, but
since the module throws an exception on import, and
module is imported on env_processing, a ValueError
will be thrown and fail completely all the tests.

Let's fail things only when actual functionality of
the module is called, during the initialization of
the BaseVirsh class.

CC: Chris Evich <cevich@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
utils.compile_gwt_clients: Use system wide GWT dir if available

This is a drop in, more generic replacement of one of the
RPM specific patches.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
scheduler.drone_manager: Write to base results dir if available

This patch is a solution for bug #502 - drone_utility does not respect
results directory. Drone manager will always use the base autotest
install directory to write results to, making it write in an out of
bounds area for the scheduler:

OSError: [Errno 13] Permission denied:
'/usr/lib/python2.7/site-packages/autotest/results'

I first thought only choosing a different

drone_installation_directory: /usr/lib/python2.7/site-packages/autotest

In /etc/autotest/global_config.ini would help, but I just realized
AUTOTEST_INSTALL_DIR is used for other purposes, such as locating
autoserv, so this change would only cause the code to break further
in the execution path. So if we have a common dir to write results
to in global_config.ini, let's use it instead of
drones.AUTOTEST_INSTALL_DIR.

Changes from v1:

 * Drop redundant 'results' suffix I was adding manually.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
scheduler.monitor_db: Find autotest-remote path accordingly

This is a followup for #502 fix. It turns out that the autotest
scheduler won't be able to find autotest-remote on a system wide
install, therefore, it won't be possible to actually install the
autotest client on test clients. Let's fix it by figuring out
whether we have an autotest-remote installed system wide, if not,
fall back to the usual /autotest/path/server/autoserv.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
scheduler.monitor_db_watcher: Figure out results dir and scheduler path

This is another packaging related fix, we can figure out
autotest-scheduler path with os_dep in case of system wide
install, if not there fall back to the original way of
determining both scheduler and results directory.

It needs some testing to see if it doesn't break stuff I
didn't anticipate.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
scheduler/tko: Add autotest-tko-parse v2

On a system wide install, in order to successfuly parse
autotest server results, the parse utility must be available.

So let's create the new system wide installable autotest-tko-parse,
and adapt the scheduler to call it correctly.

Changes from v1:
 * parse.main() must be called rather than just main()

CC: Cleber Rosa <crosa@redhat.com>
CC: Martin Krizek <mkrizek@redhat.com>
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
Add new system wide installable entry points

So autotest-local can effectively run under autotest-remote.
Handle client push in a way that it can also install the
entry points in system wide locations, and code can also
figure out those system wide locations are present.

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>