Merge lp://staging/~cjohnston/ubuntu-ci-services-itself/ts-ticket-read-api into lp://staging/ubuntu-ci-services-itself

Hi Chris,

I have one question:

Other components will need to reach subtickets directly to update their status, for example the Lander needs to reach the subticket to mark it as built. AFAIK all other components will use the Ticket ID to reach it, so we'd need to do something like api/v1/ticket/foobar/123, 'foobar' being the source package name and 123 the ticket ID. Is that possible with tastypie? If not, we could do something like 'foobar-123' and parse it. This way you wouldn't need to expose subticket directly, as it would be only used internally, considering the fullticket displays all subtickets and for WebUI purposes that should be enough.

Of course, this approach works considering there will be only one source package upload in active state per source package in a ticket -- others can correct me if I'm wrong and we should consider several landings of the same SP in a single ticket.

Cheers,

I believe what your referring to here can be accomplished by nested
resources from tastypie, however IMO it is outside the scope of this MP.
This MP is purely for consuming data from the ticket system, mainly for the
web UI. Any other concerns with this MP?

For the initial phase, the lander and other internal components will not be sending updates via the REST API. The only consumers for the this API should be the front end web ui.

Francis, how will the ticket statuses be kept up to date?

> Francis, how will the ticket statuses be kept up to date?

The original design had the ticket system polling the lander for progress. This was updated to use a message queue instead. The ticket system provides a message queue handle to the lander as part of the execute_request call. The lander then uses this to provide regular progress updates (every 60 seconds or sooner if status changes). The exact details of what is in the message haven't been designed yet, but it would probably have to provide the status of all lander stages in each message. For example:

{"Package Building": "Completed",
 "Image Building": "In Progress",
 "Image Testing": "Not Started",
 "Package Publishing": "Not Started"}

Ok, so the TS will be polling the message queue looking for status changes?

> Ok, so the TS will be polling the message queue looking for status changes?

That's my understanding, confirmed by fginther:
<Ursinha> fginther, let me see if I got the message queue idea: "Lander" updates whatever it is in the message queue, ticket system polls the message queue for updates, therefore there's no need of a write API to update ticket status for phase 0?
<fginther> Ursinha, yes, you're correct

(slightly edited for simplicity :))

On Mon, Dec 16, 2013 at 7:31 PM, Ursula Junque <email address hidden> wrote:

> That's my understanding, confirmed by fginther:
> <Ursinha> fginther, let me see if I got the message queue idea: "Lander"
> updates whatever it is in the message queue, ticket system polls the
> message queue for updates, therefore there's no need of a write API to
> update ticket status for phase 0?
> <fginther> Ursinha, yes, you're correct
>

We have a "rabbit worker" example that you can steal from to get started:

http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-ci-services-itself/trunk/view/head:/branch-source-builder/run_worker

Its juju deployable with:

http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-ci-services-itself/trunk/view/head:/juju-deployer/branch-source-builder.yaml#L17

I'm guessing your "on_message" calls would basically be updates to the
django model or something

For phase 0 I think this is okay, I'll make the necessary changes for subticket when we need it later.