On Mon, Sep 12, 2016 at 11:39 PM, Tim Flink <tflink(a)redhat.com> wrote:
I think we talked about this in person earlier but I didn't write any
notes about it and I don't recall the details.
How exactly are we going to be using Groups? The first thing that comes
to mind is to group results by execution so that there would be a group
of results which were all produced from the same run of the same task.
That's kinda what we're using Job for in resultsdb 1.0 right now,
I realize that the docs for resultsdb are supposed to be
not-specific-to-taskotron but was there anything else we thought the
Group might be useful for?
Also, what do we want to do about a link to execdb? If we're planning
to have a group for each execution's results, that could be the group's
ref_url but that relies on convention which could change if Group is
used for more than just grouping results by execution.
I see two (maybe three) options - either we'll be using the groups in the
same way we used
Jobs - to group results per execution as we do now, and use the group's
ref_url to point to execdb. If we ever need to use the groups for more than
then we could just have the result in more than one group, and set
The other way would be to not use Groups at all, and just store the execdb's
UUID in the key-value store. Those would then be rendered to an URL in
Last option would be a combination of both - we'd be using Groups as we do
to group by execution, but instead of the "default" resultsdb_frontend,
something tailored for taskotron - we could show links to execdb in the
"view", and either disregard the existence of groups alltogether, or just
a special description (like "ExecDB related Group - ....") that would get
out in the default "group" view.
I don't really see one being directly better than the others it's just what
want to do. I did not put much thought to it, as I just expected us to keep
basically the same.
Do you have any ideas?
I assume that the new API will also help fix some of the slowness
been seeing? IIRC, there were some schema changes which would probably
help with query time.
Yep, most of what was really slow should be solved now - or at least it
from my tests.
The only thing we still have troubles are the really sparse results - the
we thought could get solved by the new Postgres, but wasn't.
On the other hand, it is a non-issue, as long as the query is limited by
If you only care about results that are "newer than X" the amount of data
really gets cut
down, and the queries are fast, even for the sparse results, since the DB
need to crawl the whole dataset to be sure there's only LIMIT-n results.
This is how Bodhi queries the ResultsDB now - they use 'submitted'
timestamp as a
If we communicate this behaviour, I think we'll be fine. I would almost go
as far as setting
a default time-constraint to (and I'm just thinking out loud here, no
reasons for the number
whatsoever) three months, and be done with it - if you ever want older
results, just set the
time-constraint yourself, and be avare that it probably will take time. I
don't see a reason
we (as in FedoraQA and the related processes) would need to regularly
older than that anyway.