I guess we would want to take the union of all results, whichever ResultsDB instance they are appearing in. The assumption would be that the test cases are distinct.

But yeah, it is an interesting question, what happens if you have a passing result for a particular test case in one ResultsDB, and a failing result for the same test case in another? Should it be considered a pass or a fail for the purposes of the policy?

I think that edge case already exists though. There is nothing preventing a single ResultsDB from containing duplicate results for the same item and test case. Right now we just have an XXX comment to remind ourselves we have to sort by timestamp. :-) And I guess that would be the solution here too... just obey whichever ResultsDB instance has the fresher timestamp.

So it should be enough to just collect all the results from each ResultsDB instance into one big list.

So I guess instead of this break here, just extend the list each time to collect them all.

There was a meeting this morning where we talked about writing a task run by cron to sync the two resultsdb instances (CentOS CI -> Fedora) rather than having Greenwave combine the two.

@ralph, do you still want to go that route or should we consider going this direction?

@jcline, yeah - for the moment can you continue down the cron task to consolidate centos ci results into fedora's resultsdb. @mjia, thanks for taking a crack at this but there are other problems to consider too. Here are some:

• How do we handle waivers in this scenario? Waivers are stored with the resultsdb numeric id as the "foreign key", but with multiple resultsdb instances how do you know which waivers apply to which results -- there will be duplicate result ids.

• When it comes to runtime, the whole reason that the second resultsdb instance exists is because we're worried about communication between data centers. If fedora's network loses connectivity to centos - will results be lost? They're keeping a "local" copy in centos infrastructure to avoid that. Now, if greenwave queries both resultsdb results at runtime, we get ourselves back into the same problem. If net drops, then greenwave drops.

Like @jcline mentioned, he, @bowlofeggs, @pingou, and I met and talked about this for over an hour this morning and landed on trying to keep greenwave simple (with one resultsdb instance: Fedora's). We would then make a cronjob and message trigger that regularly copy results from centos resultsdb over to fedora resultsdb. At runtime, greenwave should only need to query that later instance.

@ralph , thanks for the explanation. I totally agree the idea to keep greenwave simple in this case. I'll drop this PR now.