Issue #198: Greenwave emits decision messages with 'product_version': 'fedora-*' - greenwave

greenwave

#198 Greenwave emits decision messages with 'product_version': 'fedora-*'

Closed: Fixed 5 years ago Opened 5 years ago by dcallagh.

While working on the tests I noticed a line like this:

2018-05-16 12:42:11 [pid 18505] greenwave.consumers.resultsdb DEBUG Emitted a fedmsg, {u'policies_satisfied': True, 'decision_context': 'bodhi_update_push_testing', 'product_version': 'fedora-*', 'subject': [{u'item': u'glibc-1.0-16.el7', u'type': u'koji_build'}], u'summary': u'all required tests passed', u'unsatisfied_requirements': [], u'applicable_policies': [u'taskotron_release_critical_tasks_for_testing'], 'previous': {u'summary': u'1 of 1 required test results missing', u'policies_satisfied': False, u'unsatisfied_requirements': [{u'subject_type': u'koji_build', u'scenario': None, u'testcase': u'dist.rpmdeplint', u'item': {u'item': u'glibc-1.0-16.el7', u'type': u'koji_build'}, u'subject_identifier': u'glibc-1.0-16.el7', u'type': u'test-result-missing'}], u'applicable_policies': [u'taskotron_release_critical_tasks_for_testing']}}, on the "greenwave.decision.update" topic

Note in particular 'product_version': 'fedora-*'.

I think this is a consequence of PR#160. The logic in the Resultsdb consumer, when it tries to figure out what all the possible decisions that could be made for a particular result, is looking at all the product versions appearing in all policies. But it does not have any way of knowing that a product version of 'fedora-*' is really supposed to expand to 'fedora-26', 'fedora-27', 'fedora-28' today. And in a few more months from now, 'fedora-27', 'fedora-28', 'fedora-29'.

Similar in some ways to #122 and #123: how can Greenwave know what are all the possible decisions it could be asked to make, in order to announce them?

ralph commented 5 years ago

Ack. Nice catch!

dcallagh commented 5 years ago

One possible hack, similar to https://pagure.io/waiverdb/issue/111, would be to infer the product version from the NVR of the build that the result is for.

I suppose you could similarly infer the product version from the updateid of a Bodhi update, and the name of a compose... but that starts to get messy fast.

dcallagh commented 5 years ago

Here is another, kind of related problem I just thought of:

The gating.yaml file in dist-git for a given package could refer to product versions (or decision contexts!) that don't themselves appear in the main Greenwave config. But it won't know that because it is only consulting the main config to find possible product versions right now.