On Wed, 2017-03-22 at 09:07 -0400, Kamil Paral wrote:
I know this has been a long email, but, feedback needed! :-)
So I just read through this again.
Now I get the idea somewhat better. I think it's a viable idea. I'm not
sure it's a *good* idea. It seems to add an awful lot of complexity in
order to optimize some quite specific workflows, which I thought was
kinda what we decided to get out of the business of doing, when we made
ResultsDB really simple. Writing, testing, deploying and maintaining
this middleware layer seems like it'd be a pretty sizable chunk of
work, and we'd have that extra complexity to keep in mind and debug
forever after: any time we had some kind of quirk with discovering and
displaying results, we'd have to figure out whether the bug was in the
client, the middleware, or resultsdb...
It's only my feeling, I'm not saying 'nonono don't do this'. But my
inkling is it's not the best use of resources.
It might be a useful thing to use for leverage in asking for more
hardware for resultsdb, though ;) "Well, look, if you won't give us
some more capable hardware, we're going to have to spend a ton of our
valuable time building THIS pile of bits. Is that what you want to be
paying us to do?" :P
I'm wondering if we can do something simpler and within resultsdb,
though it still *is* adding complexity: basically, add de-duplication
by specified fields as a feature to resultsdb, and let things that use
it request de-duplicated results when querying. This is something
openQA does, for whatever that's worth: when querying openQA directly,
I can request that it give me only the 'latest' results, which
translates to it de-duplicating by scenario on the server side.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net