| Age | Commit message (Collapse) | Author | 
 | 
Also only sleep between fetches if we couldn't find a job because
the queue was empty.
 | 
 | 
 | 
 | 
This was an invalid comment, the timeout related to HTTP-fetches.
 | 
 | 
 | 
 | 
We now parse a single test-definition into multiple
test-implementations.  This isn't required here because
the parser only needs to know that the configuration file
*can* be parsed, not what the result is.
Validate that we got an array, but otherwise ignore the
results after the first.
 | 
 | 
 | 
 | 
This is a stub for the moment, but it validates that we can have
multiple handlers for a given test-type.
This updates #9558.
 | 
 | 
 | 
 | 
We need to do this such that we can show all possible results
of a test in the status-page.  There might be three back-ends
with different results and if we filter by class-type we'll
be able to see that.
 | 
 | 
The new approach uses the redis gems timeout functionality
and ensures we never return a null-job.  Instead we timeout
and repeat with a stalling-sleep in the way.
This closes #9553.
 | 
 | 
 | 
 | 
 | 
 | 
As soon as we allow multiple test-implementations we get
into a mess, as Mauve regards an ID as unique and that is
based upon the test-definition not the implementing method
We want to allow:
* HTTPS test to succeed.
* SSL-check to fail.
Which means multiple tests of type "https" will have different
IDs.  Force this by adding on the class of the implementation.
 | 
 | 
 | 
 | 
a given input-line.
 | 
 | 
We now work on the assumption that a single "job", pulled from
the queue, might contain multiple "test" objects.  These are
the instances of the protocol-testers which we actually execute.
This is part of #9558.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
The redis-state "alerter" saves state in a useful way for the
future, and will now save an array of hashes - each has corresponding
to a useful result.
 | 
 | 
 | 
 | 
We now record:
    custodian.$type.$host.test_duration [time]
 | 
 | 
 | 
 | 
Rather than passing our settings-object around, as well as
specific settings that are read from it, just pass the object.
The worker can read the settings directly if/when it needs to.
 | 
 | 
We now set the queue-address via $QUEUE_ADDRESS, otherwise
we default to localhost.  This works for both redis & beanstalkd.
 | 
 | 
Now that we've moved to using redis by default the handling of queue-flushing
needs to change.  We can simply get rid of the busy-wait and run a redis
"del" operation.
With that in mind we've moved the flushing logic to our queue abstraction
layer, and simplified our queue-helper script.
 | 
 | 
 | 
 | 
This refereed to ruby1.8 in a versioned way which was wrong.
 | 
 | 
 | 
 | 
(i.e. "pxe.io must not run mx otherwise 'no mail for steve'.")
 | 
 | 
Default to redis as this is more likely to be installed.
 | 
 | 
This replaces redis as a hard-wired default.
 | 
 | 
This means we can queue/dequeue to either Redis or Beanstalkd.
 | 
 | 
We now connec to the MX-servers via XX:25 and alert if that
fails.:wq
 | 
 | 
 | 
 | 
This will perform a DNS-lookup AND SMTP-test for the given
domain.
 | 
 | 
This is not-yet used, but it will-be shortly.  The intention is
that we can seamlessly swap out the queue implemention in the
near future so that we'll be able to use Redis.
 | 
 | 
We show the result we expected and what we received,
but we do so with quoted strings.  So rather than:
   * one
   * two
we show "one,two".  This closes #8538.
 | 
 | 
 | 
 | 
which protocol to use.
 | 
 | 
 | 
 | 
 | 
 | 
compare stuff.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 |