#123 Greenwave has different expectations for consumers making direct requests vs. listening to fedmsgs
Closed: Fixed 3 years ago Opened 3 years ago by adamwill.

I thought I saw some issues in the fedmsg decision emitter causing wrong decisions, but @dcallagh explained to me that it's not quite that simple. There are issues, though, and this ticket is for those.

This is easiest to see by comparing how what is, I guess, the 'reference' greenwave consumer, Bodhi, generates subjects for update decision queries with how the greenwave fedmsg consumer that emits decision fedmsgs does it.

Bodhi generates a pretty big subject: the upshot of it is that it will basically pull in results and policies for every package in the update and the update itself, from every relevant test system. It should generate a single correct decision for the update: all Bodhi has to care about is that single decision, if the decision is 'no go', Bodhi blocks the update.

The decision fedmsgs...do not work like this. They use much smaller subjects. I thought this would mean they'd always return a 'no go' decision because they just wouldn't find all the results necessary to satisfy the decision contexts, but this isn't quite right. There is a filtering mechanism - the relevance_value stuff - that effectively filters policies out of the decision context if a key specified in the policy is not present in the subject (if I understood that right).

So in fact what will happen (again, AIUI) is that if all the 'relevant' policies are satisfied, a 'go' decision will be emitted, but the consumer is expected to know (how?) that this is an incomplete decision, and the update should not go out (or whatever) just on the basis of that fedmsg. The consumer is expected to know or discover somehow (again, not sure how?) that it should listen out for more 'go' decisions, until it simultaneously has 'go' decisions for all the policies in the decision context it cares about, and then push the update (or whatever).

Edit: I suppose the idea could be that the consumers are supposed to use the fedmsgs effectively as just a cue that maybe a full decision they care about has changed, and not actually work from the content of the emitted decision, but just throw it away and run their 'full fat' decision query against the Greenwave API again? Not sure.

Similarly in the case of e.g. an update with multiple packages. When Bodhi is making a direct decision request for an update it puts the identifiers for all the packages in the update into the subject, so it again basically gets a single 'go or no go' decision. But when listening for fedmsgs, it should instead listen for multiple decisions until it collects 'go' decisions for each package in the update, then be satisfied. This one makes more 'intuitive' sense than the other - it would probably be a bit odd for greenwave to know about multiple package updates and emit consolidated decisions for them - but @dcallagh seemed to think it might still constitute a problem in some sense, so I thought I'd mention it.

I'm not actually advocating any particular 'solution' to this issue here, but Dan seemed to think there was stuff to fix, so I filed the issue so we don't forget it.

I think this should be fixed by the changes in PR#184 (specifically the commit make message consumers aware of specific subject types and identifiers).

The old behaviour was that Greenwave would see a new result has appeared in Resultsdb via the message bus, then use its ANNOUNCEMENT_SUBJECT_KEYS to pick a subset of the keys from the result data and try to make a decision about that.

So in practice, a new Taskotron result about a Koji build would appear, like this:


    "data": {
      "item": [
      "type": [

and Greenwave would then check if the decision for subject [{'type': 'koji_build', 'item': 'fedpkg-1.33-1.fc26'}] had changed and send a message about that. But that's not the subject Bodhi knows or cares about, hence this bug.

The new behaviour is that Greenwave decisions are always about a single subject_type + subject_identifier pair (it's no longer a list of arbitrary dicts). Bodhi will be interested in decisions for subject type bodhi_update.

Now, when a new Taskotron result for a Koji build appears, Greenwave will determine which possible subjects the result is relevant for, and publish decisions about all of them.

In the example above, it would publish a decision for subject type koji_build with identifier fedpkg-1.33-1.fc26 and if that build is in a Bodhi update, it would publish a decision for subject type bodhi_update with the relevant updateid. The latter is what Bodhi would be listening for.

Metadata Update from @dcallagh:
- Issue assigned to dcallagh
- Issue set to the milestone: 0.8

3 years ago

Metadata Update from @lholecek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
- Issue tagged with: bug

3 years ago

Login to comment on this ticket.