So, what's the decision? I know I can "guesstimate", but I'd like to see a
group consensus before I actually start coding.
On Thu, Sep 29, 2016 at 7:31 AM, Josef Skladanka <jskla...@redhat.com>
wrote:
>
>
> 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 :)
>
> j.
>
>
_______________________________________________
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org
