If the user feeds in a yaml with targets, the worker will launch the job
but fail with
2013-09-03T11:18:34.333 CRITICAL:root:AssertionError: You cannot specify targets in a config file when using the --lock option
Just strip them out before scheduling. This eases my personal workflow
where I have a test I'm running manually against some prelocked machines
but also want to schedule it.
Signed-off-by: Sage Weil <sage@inktank.com>
This makes a run with --lock hang when connecting, for some
reason. E.g.,
$ teuthology -v a.yaml --lock
...
INFO:teuthology.task.internal:Opening connections...
DEBUG:teuthology.task.internal:connecting to ubuntu@plana06.front.sepia.ceph.com
<hangs>
No clue what is going on here, but this fixes it!
Signed-off-by: Sage Weil <sage@inktank.com>
Since getting the ostype is used multiple places I made a
function for it and modified the existing code to use
said function. I also added tests for the function.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
teuthology-suite and schedulewill now take --worker instead of
--branch. The branch is set by setting teuthology_branch in the
yaml used to schedule the job.
The teuthology branches are assumed to be in ~/teuthology-$branch
of whatever user is running the workers.
Downburst create is used to reinstall a VM when it is locked.
Downburst destroy is used to remove a VM when it is unlocked.
Host keys are regenerated on each vm instantiation, so the keys
need to be checked prior to use.
If needed, qa-ceph-chef is run on newly installed systems to insure that
they are fully functional.
Signed-off-by: Warren Usui <warren.usui@inktank.com>
Verify there is no /var/lib/ceph, just like we do with the cephtest
directory. We will need to change this (or make it optional) when we
allow runs against an existing cluster, but then a whole bunch of other
things will need to change then as well.
Signed-off-by: Sage Weil <sage@inktank.com>
Email.py was added so that the emailto attribute could be passed,
and to prevent 'module object has no attribute: email' errors from
happening. Run.py actual performs the email operation and calls
suite.email_results to do the actual send mail operation. The
information passed right now is the summary and config information.
Signed-off-by: Warren Usui <warren.usui@inktank.com>
Added the ability to support multiple types of machines with
--machine-type added to teuthology-lock when used with --lock-many
or --machine-type with teuthology --lock (automated tests). It
defaults to 'plana' and the 'vps' type is currently unused but
should be in the future.
Signed-off-by: Sandon Van Ness <sandon@van-ness.com>
Reviewed-by: Josh Durgin <josh.durgin@inktank.com>
With the addition of the --name argument to the
teuthology program (run.py), jobs were failing
because --name was being treated as a non-arg
option, even though the name was being supplied
by the workers. Fix that and give it a metavar.
Signed-off-by: Sam Lang <sam.lang@inktank.com>
teuthology-[schedule|suite] get a parameter to specify the branch,
to put the job in a branch-specific queue. Workers running that
branch of teuthology can pull jobs from that queue.
Signed-off-by: Josh Durgin <josh.durgin@inktank.com>
Especially on older hosts, we keep triggering errors::
ServerNotFoundError: Unable to find the server at
teuthology.front.sepia.ceph.com: [Errno 3] name does not exist
That comes from libevent's evdns via gevent.dns and httplib2. The rate
of these errors is low enough that they seem to be perhaps timeouts,
or more arbitrary. Busy looping on DNS resolution calls has never
triggered them, so far.
With ``monkey.patch_all(dns=False)``, the teuthology process will
block as a whole whenever doing DNS resolution. This will hopefully be
rare enough that it won't matter.
The only real "fix" seems to be upgrading libraries and hoping for the
best; this commit can be reverted after that is done.
This will make it easy for teuthology-ls to show you the running process's
pid (if it's still running). Or for other utiltizes to kill + clean up
a hung teuthology run.
