greenwave

#89 ResultsDB data is actually key -> list of values
Merged by dcallagh. Opened by dcallagh.
dcallagh/greenwave waiverdb-consumer-no-item-lists  into  master

Download 89.patch

I noticed something amiss in the waiverdb consumer test. It was passing
the subject with lists of values:

'subject': [{'item': [nvr], 'type': ['koji_build']}]

which is contrary to how all our other tests and examples work. And
contrary to how Bodhi will query the API.

This unusual value for 'subject' is not an error, and the test passes as
is, because Greenwave treats the subjects as opaque values. But when
I changed the test case to match the others, it revealed a problem.

In ResultsDB the 'data' dict is actually multi-valued:

  "data": {
    "item": [
      "python-sphinxcontrib-httpdomain-1.5.0-4.fc26"
    ],
    "type": [
      "koji_build"
    ]
  },

In theory there could be multiple values in those lists. And there could
be other, unrelated keys present too. So I'm not sure if we can reliably
map 'data' back to a 'subject' for Greenwave.

For now, let's assume there is always one value and no extra keys. This
should always be true for the test cases we know about, at least.

OK, :+1:. We should go on an expedition to see if there are any values like this in the wild.

:thumbsup:

Pull-Request has been merged by dcallagh

Expedition complete. Using a resultsdb prod dump from a week or two ago...

There are no results which have more than one value for the same key in their "data".

resultsdb=# select result_id, key, count(id) from result_data group by result_id, key having count(id) > 1;
 result_id | key | count 
-----------+-----+-------
(0 rows)

However, there are many results which have extra keys beyond just type and item. Most have scenario now. And rpmdeplint results have arch because there is a separate result for each arch tested. And OpenQA has arch, firmware, and some others.

So the waiverdb consumer won't handle those correctly I think.

Come to think of it, we also haven't considered the problem of different results-per-arch and the extra scenarios that OpenQA does (BIOS vs. EFI). This is basically the "scenarios" problem that Bodhi already had to try and deal with, as discussed in this thread:

https://lists.fedoraproject.org/archives/list/resultsdb-users@lists.fedoraproject.org/thread/DJSIOLA3YEH6HNSJEXVPLIZT5TW4CDED/

So I guess for thoses results which have extra keys, we just get the waiverdb consumer skip them for now?
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.