Learn more about these different git repos.
Other Git URLs
In bodhi/#2383, Bodhi was refactored to live query Greenwave for test results. That patch was deployed to production today as part of Bodhi 3.9.0, and now Bodhi is not displaying test results for updates.
I believe the problem is that Greenwave is not handing back test results, and that patch expects to get test results back from Greenwave:
$ curl 'https://greenwave-web-greenwave.app.os.fedoraproject.org/api/v1.0/decision' -H 'User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0' -H 'Accept: */*' -H 'Accept-Language: en-US,en;q=0.5' --compressed -H 'Content-Type: application/json' -H 'Origin: https://bodhi.fedoraproject.org' -H 'DNT: 1' -H 'Connection: keep-alive' -H 'Cache-Control: max-age=0' --data '{"product_version":"fedora-28","decision_context":"bodhi_update_push_stable","subject":[{"item":"bodhi-3.9.0-1.fc28","type":"koji_build"},{"original_spec_nvr":"bodhi-3.9.0-1.fc28"},{"item":"FEDORA-2018-01a9c96b51","type":"bodhi_update"}],"verbose":true}' { "applicable_policies": [ "taskotron_release_critical_tasks_for_stable", "atomic_ci_pipeline_results_stable" ], "policies_satisfied": true, "results": [], "satisfied_requirements": [], "summary": "no tests are required", "unsatisfied_requirements": [], "waivers": [] }
@lholecek, do you have time to take a look?
Linking this to the related bodhi issue 2554 which has related info.
Point of information: the subject bodhi-3.9.0-1.fc28 does have results in resultsdb.
bodhi-3.9.0-1.fc28
@lholecek, could this be related to your work to improve performance? IIRC, the logic goes that greenwave now only pulls results that it needs for the policy being evaluated. And, if the greenwave policy is empty (no requirements), then no results would be pulled or returned to the requester.
That performance change went out in greenwave-0.9.5. I just pinned greenwave in prod to 0.9.4, here:
https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=2735d46895668db496946da04598036abfdb4abc
... and I now see test results on updates again in the bodhi UI.
edit, @bowlofeggs - you have my permission to change the greenwave stage or prod tags at any time to get yourself out of a jam like this. Just let us know as we go.
So, the change that broke bodhi's expectations is "lazy loading" of results. Greenwave (as of 0.9.5) now checks to see what tests are required by the policy, and only loads the results that "matter" (to improve performance on the query). We want to keep that in general for lots of use cases, but this use case in the Bodhi UI needs all the results.
Proposal, let's add a new flag like the verbose flag that tells greenwave whether it should use the 0.9.5 lazy loading (this should be default, to avoid generating unnecessary load on resultsdb) or whether it should use eager loading and pull/return all results regardless of whether they're needed by the policies in play for the decision. We could call this flag eager, defaulting to false. Once implemented, Bodhi would need to start supplying the eager flag in its UI query (but not its backend queries) before we can get off the 0.9.4 greenwave release.
verbose
eager
@lholecek, @bowlofeggs: WDYT?
I just pinned greenwave in prod to 0.9.4, here: https://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=2735d46895668db496946da04598036abfdb4abc
We need to remember it's pinned there. Perhaps it's safe to only set it in Quay since moving prod tag is a manual step.
prod
I thought that verbose flag is used only for debugging purposes (it's not very well documented).
It looks like policy with no rules (rules: [] in YAML config) can be used to show all results (for a subject). That sounds like abusing the API to me.
rules: []
It would be better to have separate API to get all results (considering waivers) for given subject. Though getting all the results will make the performance suffer again.
Another solution is to allow globbing in test case names, e.g. the last line in this policy:
--- !Policy id: "taskotron_release_critical_tasks_for_stable" product_versions: - fedora-28 - fedora-27 - fedora-26 decision_context: bodhi_update_push_stable subject_type: koji_build rules: - !PassingTestCaseRule {test_case_name: "dist.*"}
I just realized that test case name globbing also doesn't make much sense since it won't tell you when a result is missing.
Anyway, I have it implemented in testcase_globbing branch.
Regarding the quay prod tag: yes, we can move that too. I wanted to do something which wouldn't be accidentally overturned with the next release.
can be used to show all results (for a subject). That sounds like abusing the API to me.
It makes it so that consumers (like Bodhi) don't need to know about resultsdb. Without this, they have to query twice which just ends up putting more load on resultsdb.
The thing is, they really do want to keep an empty policy for now and they really do want to show all test case results for the subjects. This is reasonable and is part of greenwave's value proposition: we can introduce new tests and show their results to packagers without making them mandatory. With a config change, an experimental test can be made into a gating test.
Previously, changes like that required code changes in Bodhi and its distant cousin: the Errata Tool. I think this is something we should support.
I'm fine with adding a flag, though I would have a preference for backwards compatibility. If it is decided not to be backwards compatible, I won't oppose, but note that we'll have to coordinate release schedules.
Fixed in PR#289.
I'm afraid that it breaks the performance again.
Commit 1ec1cec fixes this issue
Login to comment on this ticket.