• You shouldn't get back three unsatisfied requirements. That's a bug. The relevance_key/relevance_value stuff should kick in here to give you only one item in that list.

• The three different kinds of items you see are representative of the three kinds of subjects you asked greenwave about. :) You (bodhi) actually know those because you (bodhi) submitted them in the POSTed question. We agree that this is weird, though, and @dcallagh's API v2 stuff is meant to address it.

Ah yes, I see that now:

https://github.com/fedora-infra/bodhi/blob/3.6.1/bodhi/server/models.py#L1907-L1922

It would still be good to document what kinds of subjects I can ask about for all the reasons stated above. I actually still don't really know what they mean (I didn't write the cited Bodhi code).

For the purposes of displaying missing test results to users in the UI, how would you recommend I use the response? Should I look only at the "koji_build" type and ignore the rest? If I do that, wouldn't I potentially miss some items from the "bodhi_update" type? But if I include that too, I get duplicates which could also be confusing to users. Thoughts?

Aaaaand I did write that code:

https://github.com/fedora-infra/bodhi/commit/ea39d3c014ed4d1662637b464f7596e305dcb996

But I still don't understand it. From the link cited in the code, it seems like I just put an API call that other people said to put in there because what we had previously was not working.

Anyways, I maintain that it would be useful to document what the item types are, and I could still use advice about how to collate this information for display to users.

Sorry for so many questions @ralph, but one more: I'm noticing that Bodhi's unit tests don't really have realistic responses from Greenwave which I'm working on fixing right now. You mentioned that it's a bug that Greenwave returns all three - do you think I should just put this buggy but realistic response as example data in Bodhi's unit tests until we have the new Greenwave API, or do you think you might fix that bug in the v1 API? I'm trying to get a Bodhi release done ASAP to fix lots of the test gating UX so I'm inclined to just test Bodhi against the current response I'm seeing rather than the "correct/ideal" response, but I'd like to know your opinion on that.

I spent some time today fiddling with massaging the response I get from Greenwave into human readable HTML. What do you think?

https://github.com/fedora-infra/bodhi/issues/2335#issuecomment-385757760

Here is a PR where I am making Bodhi show unsatisfied greenwave requirements:

https://github.com/fedora-infra/bodhi/pull/2345

Note that the code explicitly filters for just the "koji_build" items and leaves out the others, as this helps avoid duplicates.

:+1: for handling the duplicates up front in Bodhi. Sorry that greenwave returns them. At this point, @dcallagh is about halfway through the api v2 stuff and I think we probably won't fix this in api v1 (as it is yet another example of the kind of workarounds that are piling up due to the api v1 deficiencies).

Will comment further on bodhi#2345. Thanks @bowlofeggs!

While testing https://github.com/fedora-infra/bodhi/pull/2345 in staging today, I found that the staging Greenwave does not return any items of type "koji_build". This means that staging Bodhi doesn't show any unsatisfied requirements. I ran the same query against production Greenwave and it did show "koji_build" in its response.

What does this mean for Bodhi? Is it a bug that stg does not show this, or a bug that production shows it? I learned that stg Greenwave is a newer version than prod - if we deploy a Bodhi to prod that relies on this and then prod Greenwave is updated, this will break Bodhi.

What advice do you have for me?

Something changed between yesterday and today in production, as Greenwave no longer includes the "koji_build" items in its response to Bodhi. This means that my patch does not show the user any of the missing tests in production. I ran the exact same query yesterday and today. Yesterday, it included "koji_build" in the unsatisfied_requirements, and today it does not. Did Greenwave get upgraded in production in the past 24 hours?

$ curl 'https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0/decision' -H 'Accept: */*' --compressed -H 'Accept-Language: en-US,en;q=0.5' -H 'Cache-Control: max-age=0' -H 'Connection: keep-alive' -H 'Content-Type: application/json' -H 'DNT: 1' -H 'Host: greenwave-web-greenwave.app.os.fedoraproject.org' -H 'Origin: https://bodhi.fedoraproject.org' -H 'User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0' --data '{"product_version":"fedora-27","decision_context":"bodhi_update_push_stable","subject":[{"item":"kernel-4.16.7-200.fc27","type":"koji_build"},{"original_spec_nvr":"kernel-4.16.7-200.fc27"},{"item":"FEDORA-2018-a13691074b","type":"bodhi_update"}],"verbose":true}' | tail -n 13
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 68643  100 68382  100   261  54444    207  0:00:01  0:00:01 --:--:-- 54608
  "summary": "1 of 2 required tests not found", 
  "unsatisfied_requirements": [
    {
      "item": {
        "original_spec_nvr": "kernel-4.16.7-200.fc27"
      }, 
      "scenario": null, 
      "testcase": "org.centos.prod.ci.pipeline.complete", 
      "type": "test-result-missing"
    }
  ], 
  "waivers": []
}

As mentioned on the list and irc, the koji_build items are no longer in the unsatisfied_requirements because they succeeded. Those requirements are actually satisfied. It's the one weird original_spec_nvr requirement from the atomic ci pipeline that's not satisfied.

This stuff should be substantially simpler now that PR#184 has landed. But I will also write up some docs to specify exactly what the structure of the decision responses is.

Closing, already documented.