Comment 6 for bug 1519894

On Jan 20, 2016, at 12:13 PM, Andy Whitcroft wrote:

>@Barry -- the consumer here has yet to be written so as long as it is
>JSON and the information is in there I am sure we can get it out just
>fine. For queue-depth yes, if we have the list of jobs for each then
>we can trivially count them (as you do in the patch).

Cool, I think I will remove queue-depth and let the client count them.

>The logtail is less obvious, if it isn't going to bloat the world I could see
>wanting that, but its no where close to a deal breaker either way.

I agree with pitti that the logtails are probably going to be too huge and not
really useful for machine parsing. Let's leave those out.

>I guess I wonder what runhash is in your description, but perhaps either
>deploy what you have, or indeed email a sample of the json from testing
>and I can try and parse it for my purposes and see if it is complete
>enough for that. Thanks for looking at this.

It looks like runhash is a way to disambiguate between running tests for the
same package/release/arch combination. AFAICT, it's calculated from the test
parameters, but it's not evident from the code what in the params is
sufficient to disambiguate the runs. In any case, it seems useful to keep
since that mirrors the internal data, and you can just treat it as opaque.

I can do a simple test run and post the JSON that results, but it likely won't
be an accurate snapshot of the complex data set you'd see on production.
Still, we can land this now and once the infrastructure's in place, it should
be quite easy to tweak the JSON format.