@ralph, could I please get some inputs on this please? Specifically, what kind of identifiers should be used for those absent results when creating waivers? If we do not use identifiers, changing `result_id' to not required, how would Greenwave to query those waivers?

I just realized that this might block FACTORY-1070 since users may want to waive this kind of results in Bodhi as well.

"How things work now":

• Users submit waivers to waiverdb in terms of a result_id.
• When a user (or system) queries greenwave for a decision, it does so in terms of a subject. This is a list of dicts that each represent queries to resultsdb. A query subject to greenwave might look like [{item: 'python-requests-1.2.3-1.el7', type: 'koji_build'}].
• Greenwave takes each entry in the subject list and queries resultsdb for all matching results. This gives greenwave a list of results.
• Greenwave then takes the results_id for each of those results and queries waiverdb for any matching waivers.

We could refactor waiverdb to not store waivers in terms of result_id values, but instead in terms of these subject entries.

note: storing waivers in terms of a result_id before had the benefit of making things simple in waiverdb. It didn't need to know very much - just the numeric result_id. Now, a waiver would need to be stored both in terms of a subject and a testcase.

Here's an example. We'll use a different (but legitimate) subject just to demonstrate how subjects can be quite different.

• A user could submit a waiver to waiverdb for the subject{'productmd.compose.id': 'Fedora-9000-19700101.n.18'} and the testcase 'compose.install_no_user' (which is a real testcase for Fedora's rawhide composes). See examples in fedora's resultsdb.
• Greenwave, when asked about a subject [{'productmd.compose.id': 'Fedora-9000-19700101.n.18'}] would query resultsdb for all results associated with that subject. Let's say it found none, because the compose.install_no_user test was broken, and never ran.
• Greenwave would then turn around and ask waiverdb for all waivers associated with that same subject. If the returned testcases were for waivers in greenwave's policy then it would include those waivers in its calculation.

Thanks, @ralph. I like this approach.

Would we need to continue supporting waivers against result ids too?

Is there ever a situation where we have a result and we want to waive it before we know what subject we will be querying for that might pick up that result? If we assume everything goes through Greenwave then... I think no.

@dcallagh I don't know if that answers to your question, but I've completely removed the result_id field from the waiverdb database... So it will not any more possible to waive some result with the result_id...

@gnaponie hmm when you say "you have removed", I guess you are just talking about some patch you have locally? I don't see any open pull requests or merged commits for this issue. Are you actively working on it right now?

Oh I just found all your discussions about this on the internal JIRA copy of this issue. I didn't realise.

In future it would be nice to try and keep discussions here in the public issue tracker, instead of our internal JIRA, in case people from outside Red Hat want to see or contribute to the discussion.

Oh ok, I'm sorry, I didn't know that, and I thought I had assigned already the issue, but seems I forgot about that. I'll keep it in mind for the next time.
Thank you for the information

Just to make it easier to find the right PR for this bug: https://pagure.io/waiverdb/pull-request/99

Closing. This should go out in the next release.