> On Tue, Sep 27, 2016 at 6:06 PM, Kamil Paral < kpa...@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.
_______________________________________________
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
