On Wed, 2017-03-01 at 11:47 -0500, Kamil Paral wrote:
Also, I realized we could add the "scenario" key to the
testcase
object, not the result object (if it's not possible now, we could add
it). So it would be easy to just retrieve the testcase info a figure
out how to structure your query in order to get unique results.
Resultsdb would still stay a dumb storage, of course, this would be a
consumer logic.
Yeah, I think that was one thing I was thinking of, but I'm not sure I
really like it. I think I kinda prefer just having an actual 'scenario'
*value* for each result.
Another use case I'm pondering right now is the new /latest
endpoint
in ResultsDB 2.0. It should give you only the latest result for each
available testcase, therefore sparing you from performing expensive
queries (either a lot of them, for each testcase, for raising the
time delta limit too much). Example:
http://taskotron-dev.fedoraproject.org/resultsdb_api/api/v2.0/results
/latest?item=netpbm-10.77.00-3.fc24
But that currently breaks for depcheck, because it reports results
separately for each arch. So for some testcases, we need to be able
to say "you must consider 'arch' when deciding uniqueness". You can
of course add "&arch=x86_64" to the /latest query, but a) how do you
know all the possible arch values? b) that won't give you any results
which don't use 'arch' keyword.
So, we need to come up with a way how to make this easy for consumers
(so that they don't need to know every single detail for each task,
if possible), but still keep the logic outside of the database (if we
want to keep resultsdb data agnostic). I assume we could be able to
make that happen using reporting conventions, maybe even forcing them
for some (the important) tasks. Ideas?
Well, yeah, this is really *exactly* the same case: you're just talking
about the 'scenario' for depcheck tests. My suggestion is that depcheck
tests should simply have an extradata value like:
scenario: depcheck.x86_64
Note that this kind of thing is *exactly* why openQA came up with the
'scenario' concept; they realized they kept reinventing this "well, is
job X 'the same as' job Y?" logic in different contexts (the web UI
code, API queries, a bunch of different places). They have exactly your
use case, among others - a /latest endpoint. So they realized the
concept needed to be defined and shared between all those places, and
came up with the 'scenario' naming.
I hope you can see that we're really in the same use case? With my
idea, your 'latest' endpoint would simply look for all results for the
specified item then de-duplicate them by scenario. It wouldn't need to
consider any other metadata at all, just the scenario would be enough.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net