Taskotron Fedmsgs Format

[Martin Krizek]

Please find proposed format for taskotron fedmsgs below.

{ 'i': 1,
   'msg': {'check': {'name': 'upgradepath',
                     'type': 'bodhi_update', 
                     'item': 'wireshark-1.10.12-1.fc20',
                     'arch': 'x86_64'},
           'packages': [{'nvr': 'wireshark-1.10.12-1.fc20',
'name': 'wireshark'}],
           'result': {'id': 123456,
                      'submit_time': '2015-01-27 14:22:53.584210',
                      'outcome': 'failed',
                      'summary': '...',
                      'job_url':
'http://resultsdb.fedoraproject.org/...',
                      'log_url':
'http://taskotron.fedoraproject.org/...'}
   },
   'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d',
   'timestamp': 1395760459,
   'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new',
   'username': 'taskotron'
}

The 'packages' field would be used for all the packages that are relevant
to the check which result is being sent in the fedmsg, so they can be
returned by fedmsg.meta.msg2packages and searched on using datagrepper.


Thoughts?

Thanks,
Martin

[Ralph Bean]

On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
>  Please find proposed format for taskotron fedmsgs below.
>  
>  { 'i': 1,
>     'msg': {'check': {'name': 'upgradepath',
>                       'type': 'bodhi_update', 
>                       'item': 'wireshark-1.10.12-1.fc20',
>                       'arch': 'x86_64'},
>             'packages': [{'nvr': 'wireshark-1.10.12-1.fc20',
> 'name': 'wireshark'}],
>             'result': {'id': 123456,
>                        'submit_time': '2015-01-27 14:22:53.584210',
>                        'outcome': 'failed',
>                        'summary': '...',
>                        'job_url':
> 'http://resultsdb.fedoraproject.org/...',
>                        'log_url':
> 'http://taskotron.fedoraproject.org/...'}
>     },
>     'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d',
>     'timestamp': 1395760459,
>     'topic': 'org.fedoraproject.{prod, stg, dev}.taskotron.result.new',
>     'username': 'taskotron'
>  }
>  
>  The 'packages' field would be used for all the packages that are relevant
>  to the check which result is being sent in the fedmsg, so they can be
>  returned by fedmsg.meta.msg2packages and searched on using datagrepper. 
Looks quite good to me.  :)

So depcheck results would include a long list of relevant packages?

[Tim Flink]

On Wed, 28 Jan 2015 13:42:23 -0500
Ralph Bean <rbean(a)redhat.com&gt; wrote:

>  On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
>  > Please find proposed format for taskotron fedmsgs below.
>  > 
>  > { 'i': 1,
>  >    'msg': {'check': {'name': 'upgradepath',
>  >                      'type': 'bodhi_update', 
>  >                      'item': 'wireshark-1.10.12-1.fc20',
>  >                      'arch': 'x86_64'},
>  >            'packages': [{'nvr': 'wireshark-1.10.12-1.fc20',
> 'name':
>  > 'wireshark'}], 'result': {'id': 123456,
>  >                       'submit_time': '2015-01-27 14:22:53.584210',
>  >                       'outcome': 'failed',
>  >                       'summary': '...',
>  >                       'job_url':
>  > 'http://resultsdb.fedoraproject.org/...', 'log_url':
>  > 'http://taskotron.fedoraproject.org/...'} },
>  >    'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d',
>  >    'timestamp': 1395760459,
>  >    'topic': 'org.fedoraproject.{prod, stg,
>  > dev}.taskotron.result.new', 'username': 'taskotron'
>  > }
>  > 
>  > The 'packages' field would be used for all the packages that are
>  > relevant to the check which result is being sent in the fedmsg, so
>  > they can be returned by fedmsg.meta.msg2packages and searched on
>  > using datagrepper.
>  
>  Looks quite good to me.  :)
>  
>  So depcheck results would include a long list of relevant packages? 
It could, yes. The native output format of depcheck is per-rpm but
we've always considered updates to be the lowest-level unit against
which depcheck reports because it doesn't make sense to fail only part
of an update. However, I think we can add a list of affected packages
to the fedmsgs emitted for depcheck results.

The thing I'm wondering is if there are interesting use cases which
aren't well covered by this. Package-specific checks wouldn't be a
problem, nor would image-based checks. The only thing I can think of
that may not work so well is stuff like the gnome-installed-tests which
aren't specific to a single package or a single deliverable. Would FMN
allow for folks to subscribe to messages from a specific check or are
only certain fields capable of triggering notification?

Tim

[Ralph Bean]

On Thu, Jan 29, 2015 at 08:53:22AM -0700, Tim Flink wrote:
>  On Wed, 28 Jan 2015 13:42:23 -0500
>  Ralph Bean <rbean(a)redhat.com&gt; wrote:
>  
>  > On Wed, Jan 28, 2015 at 12:29:29PM -0500, Martin Krizek wrote:
>  > > Please find proposed format for taskotron fedmsgs below.
>  > > 
>  > > { 'i': 1,
>  > >    'msg': {'check': {'name': 'upgradepath',
>  > >                      'type': 'bodhi_update', 
>  > >                      'item': 'wireshark-1.10.12-1.fc20',
>  > >                      'arch': 'x86_64'},
>  > >            'packages': [{'nvr':
> 'wireshark-1.10.12-1.fc20', 'name':
>  > > 'wireshark'}], 'result': {'id': 123456,
>  > >                       'submit_time': '2015-01-27
> 14:22:53.584210',
>  > >                       'outcome': 'failed',
>  > >                       'summary': '...',
>  > >                       'job_url':
>  > > 'http://resultsdb.fedoraproject.org/...', 'log_url':
>  > > 'http://taskotron.fedoraproject.org/...'} },
>  > >    'msg_id': '2014-0bc98222-a864-4aea-bc6b-e3b090d2cc3d',
>  > >    'timestamp': 1395760459,
>  > >    'topic': 'org.fedoraproject.{prod, stg,
>  > > dev}.taskotron.result.new', 'username': 'taskotron'
>  > > }
>  > > 
>  > > The 'packages' field would be used for all the packages that are
>  > > relevant to the check which result is being sent in the fedmsg, so
>  > > they can be returned by fedmsg.meta.msg2packages and searched on
>  > > using datagrepper.
>  > 
>  > Looks quite good to me.  :)
>  > 
>  > So depcheck results would include a long list of relevant packages?
>  
>  It could, yes. The native output format of depcheck is per-rpm but
>  we've always considered updates to be the lowest-level unit against
>  which depcheck reports because it doesn't make sense to fail only part
>  of an update. However, I think we can add a list of affected packages
>  to the fedmsgs emitted for depcheck results.
>  
>  The thing I'm wondering is if there are interesting use cases which
>  aren't well covered by this. Package-specific checks wouldn't be a
>  problem, nor would image-based checks. The only thing I can think of
>  that may not work so well is stuff like the gnome-installed-tests which
>  aren't specific to a single package or a single deliverable. Would FMN
>  allow for folks to subscribe to messages from a specific check or are
>  only certain fields capable of triggering notification? 
Yeah, we could write a specific FMN rule for specific taskotron
checks.  They are just little python functions that accept a message
and return true or false.

See https://github.com/fedora-infra/fmn.rules/tree/develop/fmn/rules