On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral < kparal(a)redhat.com
> wrote:
> ...
> What are the use cases? I can think of one - yesterday Adam mentioned he
> would like to save manual test results into resultsdb (using a frontend).
> That would have no ExecDB entry (no UUID). Is that a problem in the current
> design? This also means we would probably not create a group for this
> result
> - is that also OK?
Having no ExecDB entry is not a problem, although it provides global
UUID for
our execution, the UUID from ExecDB is not necessary at all for ResultsDB
(or the manual-testing-frontend). The point of ExecDB's UUID is to be able
to tie together the whole automated run from the point of Trigger to the
ResultsDB. But ResultsDB can (and does, if used that way) create Group UUIDs
on its own. So we could still create a groups for the manual tests - e.g.
per build - if we wanted to, the groups are made to be more usable (and
easier to use) than the old jobs. But we definitely could do without them,
just selecting the right results would (IMHO) be a bit more complicated
without the groups.
The thing here (which I guess is not that obvious) is, that there
are
different kinds of UUIDS, and that you can generate "non-random" ones, based
on namespace and name- this is what we're going to use in OpenQA, for
example, where we struggled with the "old"design of ResultsDB (you needed to
create the Job during trigger time, and then propagate the id, so it's
available in the end, at report time). We are going to use something like
`uuid.uuid3("OpenQA in Fedora", "Build
Fedora-Rawhide-20160928.n.0")`
(pseudocode to some extent), to create the same group UUID for the same
build. This approach can be easily replicated anywhere, to provide canonical
UUIDs, if needed.
Hope that I was at least a bit on topic :)
Very much. Thanks for an exhaustive answer.
So, what's the decision? I know I can "guesstimate",
but I'd like to see a group consensus before I actually start coding.
I'll just summarize here that we discussed this during Monday's qa-devel meeting
and reached consensus that keeping ref_url in the group (as it used to be) is the current
way forward.