Merge lp:~vila/ubuntu-ci-services-itself/testy into lp:ubuntu-ci-services-itself
| Status: | Merged |
|---|---|
| Approved by: | Francis Ginther |
| Approved revision: | no longer in the source branch. |
| Merged at revision: | 14 |
| Proposed branch: | lp:~vila/ubuntu-ci-services-itself/testy |
| Merge into: | lp:ubuntu-ci-services-itself |
| Diff against target: |
402 lines (+112/-56) 8 files modified
docs/components/existing-pieces.rst (+1/-1) docs/components/landing-manager.rst (+4/-4) docs/components/planned.rst (+1/-1) docs/components/test-runner.rst (+75/-19) docs/components/ticket-manager.rst (+3/-3) docs/components/ticket-system.rst (+1/-1) docs/sequence.rst (+23/-23) docs/timeline.rst (+4/-4) |
| To merge this branch: | bzr merge lp:~vila/ubuntu-ci-services-itself/testy |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Francis Ginther | Approve | ||
|
Review via email:
|
|||
Commit message
Update the Test Runner component design and provide the initial API.
Description of the change
Main changes from the trunk version:
* 'test_image' request
s/test_
/test_
The rationale is that the caller should do multiple requests if it needs
multiple test results (otherwise the 'done' request will have to aggregate
the results and the artifacts and the caller will have to sort them out =>
unneeded complexity).
* handles a single DEP8 package which produce a single test result and a
list of artifacts (phase0). For following phases, I'd like to embed the
articats in the test result itself as discussed during the 'subunit'
hangout. For now, the request will contain them all, leaving the caller
store them as it sees fit.
The rationale is that asking this component to know about the data store
is coupling them for no good reason.
* new requests: 'done' and 'progress'
Questions:
* messages exchanged between components
We talked about REST APIs and about task queues. I more or less assumed that
a request is added to a queue as a task and the response is sent back when
the task is done (from the queue POV). Feedback welcome.
For the 'done' request, the above works ok, but if we want a REST API and no
queue, I need to know *where* to send that request (some url provided as
part of the 'test_package' request parameters ?).
* progress
Emitting progress and providing an ETA or some estimate of the work already
done raise two issues:
- how many messages should be sent or alternatively at which rate ? Emitting
the same number of messages for a 1 minute job and a several hours one
doesn't make much sense. It seems to me that one message very minute or
every 30 seconds should be enough. But at scale, that may still be far too
much messages. Thoughts ?
- ETA is a pipe dream so let's settle for estimates to start with. This can
be be based on the number of tests as long as each test is shorter than
the interval between two messages. If it's not, we risk misreadings
between a long test and a hanging test.
If we don't get good ideas there, I'd settle with some arbitrary interval
for phase 0 and plan to acquire the number of tests to initialize 'total'.
| Andy Doan (doanac) wrote | # |
On 12/06/2013 09:34 AM, Vincent Ladeuil wrote:
> + test_image(
> +This ends the processing of a 'done' request and is sent to the 'Landing
> +Manager'.
> + done(test_
This introduces a new decision for us to make. In the
branch-
appears to be the same concept as your "test_request_id". So the first
decision is simply agreeing on a common name for this thing.
The thing where the branch-
creates progress_trigger. In its design, the caller passes this value.
In your design the implementation creates and returns the value. I don't
have a strong opinion. However, I suspect the branch-
approach will be more HA friendly. eg, it can create this object and
persist it somehow for the service. If the calling service dies while
the request is being processed, its okay. The messages will get queued
up somewhere to be determined, and when the back-up service comes back
online it will know about this progress_trigger and be able to catch
back up with the queued responses.