Maybe /v1.1? :-) Bikeshed...

:customs: /v2/ :customs:

For further background/discussion, see #74, #122, #123.

This will also be our opportunity to figure out a way to handle RPMDiff results (type of koji_build_pair) and also test results for Bodhi updates that have since been edited, invalidating the results. We have completely punted on those issues up until now.

So the simplest possible change here would be to just replace the subject list of dicts with two new parameters, say subject_type and subject_identifier.

Then the various messy details about how to look up results and waivers for each subject type will be encapsulated inside Greenwave.

We know about three subject types so far:

• Koji builds
• Bodhi updates (or more generally, "distribution updates" which Errata Tool advisories are too)
• Composes

In the case of Bodhi updates which consist of multiple Koji builds, we could force Bodhi to query/listen for separate decisions about the update itself, in addition to all the builds in the update.

To me, this feels like moving too much of the burden into Bodhi and kind of defeats the purpose of Greenwave.

Alternatively, we could make Greenwave aware of which builds are in which updates (either by querying Bodhi or listening for messages) and then Greenwave is responsible for giving a complete answer when asked about an update including all the builds in it.

Or we could pursue the idea I mentioned already in #74. Instead of the subject type being "Bodhi update" it would be "set of Koji builds". This requires a change in how OpenQA (also the rpmdeplint Taskotron task, maybe???) report their results. I should follow up with Fedora QA.

Talked about this this evening. Takeaway for me:

• We have to get into a situation where new greenwave code is required to be able to answer new kinds of questions.
• Thinking about this as a spectrum between having the client (bodhi-server) have to specify a bunch of information in the question and greenwave knowing how to divine a bunch of information at question time is helpful. Next, realize that greenwave's message-producing code turns it into one of its own client systems. This forces our design down one end of the spectrum.
• I think that subject_type is probably the least expensive axis along which to have to add new code.

A world where greenwave actively persists knowledge about other systems may end up being helpful here for performance reasons. For sanity's sake, let's put that off into a second effort after we've refactored the API here.

Note to self: prepare a demo video for this new API when it is implemented.

I haven't implemented this yet. But to make it more concrete, this is the change we are proposing (shown as a diff against the POST /api/v1.0/decision docs):

--- a/greenwave/api_v1.py
+++ b/greenwave/api_v1.py
@@ -119,7 +119,8 @@ def make_decision():
        {
            "decision_context": "bodhi_update_push_stable",
            "product_version": "fedora-26",
-           "subject": [{"item": "glibc-1.0-1.fc26", "type": "koji_build"}],
+           "subject_type": "koji_build",
+           "subject_identifier": "glibc-1.0-1.fc26",
            "verbose": true
        }

More importantly, a decision for a Bodhi update would change from the current request, like this:

{
    "product_version": "fedora-27",
    "decision_context": "bodhi_update_push_stable",
    "subject": [
        {"type": "bodhi_update", "item": "FEDORA-2018-5a6cc3f4a2"},
        {"type": "koji_build", "item": "akonadi-calendar-tools-17.12.1-1.fc27"},
        {"type": "koji_build", "item": "akonadiconsole-17.12.1-1.fc27"},
        ...,
        {"original_spec_nvr": "akonadi-calendar-tools-17.12.1-1.fc27"},
        {"original_spec_nvr": "akonadiconsole-17.12.1-1.fc27"},
        ...
    ]
}

to this:

{
    "product_version": "fedora-27",
    "decision_context": "bodhi_update_push_stable",
    "subject_type": "bodhi_update",
    "subject_identifier": "FEDORA-2018-5a6cc3f4a2"
}

Greenwave will understand which builds are currently in the update, and it will do the hard work of figuring out which results and waivers are applicable to those builds and to the update itself, instead of making the caller try to express all that in the subject of the request.

PR#184 implements this. It's close although not quite ready to merge yet.