This might be crying wolf, but reading through the comment from @ralph, I am not sure if he meant reusing the already existing verbose flag, but rather adding a new flag called eager which would work in a similarly to verbose.

But I might be misreading things or missing some context/discussions.

I would rather omit adding another flag but I'm open to it.

This works for me. @mvadkert, do you have an opinion?

@lholecek wrote a change previously that made it so that greenwave only retrieves and returns the results that are relevant for a given decision_context. This was meant to reduce load on resultsdb -- greenwave won't have to query for loads and loads of irrelevant results.

We discovered yesterday that Bodhi expects to get all the results (both relevant and irrelevant) for a given subject, to display them in the UI.

IIRC, you use the verbose flag today somewhere in your gating mechanisms. Do you have an opinion on if we should re-use the verbose flag for this behavior or if we should add a new separate flag to control the "all results or only the relevant ones" behavior?

@lholecek @ralph Yeah, I use that flag. What I need is being able to distinguish between decision updates that have policy satisfied and actually have some satisfied requirements and those which do not have any. The latter is basically a skip for the gating bot, the former means I need to tag back the build. If this change does not affect satisfied_requirements, I should be fine.

It does not change or affect satisfied_requirements.

.. but, is the only way to get satisfied_requirements to keep using the verbose flag?

We want you to be able to get off of retrieving all results from resultsdb unnecessarily.

@lholecek, wdyt? With this change, can we start returning satisifed_requirements even when verbose=false so that @mvadkert can stop requesting verbose=true?

With this change, can we start returning satisifed_requirements even when verbose=false so that @mvadkert can stop requesting verbose=true?

Fine with me, there shouldn't be any problem: PR#290

Nice! :+1: from me here, assuming #290 is in good shape.

+1

It does not change or affect satisfied_requirements.
.. but, is the only way to get satisfied_requirements to keep using the verbose flag?
We want you to be able to get off of retrieving all results from resultsdb unnecessarily.

I guess that would work yeah, if both, satisfied and unsatisfied requirements are returned without setting the verbose flag, I do not need to query with verbose.

+1

Commit 25f5db1d fixes this pull-request