it looks ok :+1:

:+1: here too.

Oops, funny typo in commit message subject (s/Upset/Update/). :)

Yeah, don't upset the release notes, what did they ever do to you? :-P

Can we combine with this the entry above, about subject_type? Specifically the (undocumented) relevance_key and relevance_value attributes in the policy should be replaced with a suitable subject_type.

The changes were way more than just the policies though. It was also API changes across the decision endpoint and message formats as well. As in Waiverdb we really need to enumerate what exactly is new, why it is useful, and how to start using it.

Interesting. Will this mean that calls from Bodhi to Greenwave will result in Greenwave calling Bodhi's API? If so, we should be careful not to make the /updates// API handler call Greenwave as a convenience, because that would be a hilarious game of ping pong.

Nice!

LGTM

@bowlofeggs Yeah, that would be a deadlock. Greenwave would be making waiting on Bodhi and Bodhi in turn on Greenwave. The request would time out eventually (15 seconds by default I think) but Greenwave doesn't handle requests asynchronously so it would be unusable for the time.

The text of the cross-reference may change in future, so it would be better to write out the new name of the class here, and then just refer to the docs after it. Like this:

renamed to ``RemoteRule``. See :ref:`remote-rule` (#220).

Also on the line above and in a few other places you have accidentally used a "bare role" with single backticks instead of code snippet with double backticks.

I used single ticks because they where used elsewhere in this doc. Anyway, I'm fixing it.

I think we should elaborate on this a tiny bit more. As Randy already noticed this is actually a whole new feature that is worth describing fully.

Previously when you wanted to ask Greenwave for a decision about a Bodhi update, you had to also pass in all the NVRs of the builds in the update as well. Now, you just ask about the Bodhi update. Greenwave can query Bodhi to find the builds in the update, and will apply the relevant policies for those builds as well. The BODHI_URL config setting must be set for this feature to work.

A small nit... instead of "become" can we say "should be changed to". This makes it clear that there is action required from the admin, it does not magically get converted for them.

Of course it's kind of moot because this only affects the Fedora deployment and we will make sure the configuration there is updated ourselves... but I think we should keep up good habits anyway.

Ah I didn't see you had already updated this lholecek. Remember that Pagure doesn't send any notification when you amend a PR.

Looks good now, :+1: from me

Commit 63429d66 fixes this pull-request