dgilmore noted in channel that the koji fedmsg plugin is producing tracebacks like the following:
Error running postBuildStateChange callback from _koji_plugin__fedmsg-koji-plugin: Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/koji/plugin.py", line 165, in run_callbacks func(cbtype, *args, **kws) File "/usr/lib/koji-hub-plugins/fedmsg-koji-plugin.py", line 94, in send_message body = get_message_body(topic, *args, **kws) File "/usr/lib/koji-hub-plugins/fedmsg-koji-plugin.py", line 50, in get_message_body msg['owner'] = kojihub.get_user(info['owner_id'])['name'] KeyError: 'owner_id'
The error is not occurring for *all* postBuildStateChange calls, only for some. We are not sure if this has been happening since the fedmsg plugin was introduced or if it is a result of the koji upgrade that happened last night. It is not causing koji to fail, but the subset of build state change messages that hit this traceback are not being published. It is also adding noise to the koji logs.
The koji fedmsg plugin is kept in puppet, so we can patch it there (it is not in an rpm). The following patch should do the trick: http://ralph.fedorapeople.org/0001-Silence-intermittant-koji-tracebacks.patc...
For some messages, a None (null in json) will be published for the first time in the owner field. The code that parses those messages on the consuming side can be found here: http://bit.ly/16jqhtq It looks like it can handle a None without causing any further issues. I can't say for certain about any third-party code that may be listening to koji/buildsys messages and whether or not it can handle a None/null.
I'm looking for two +1s to apply the patch above to clean up the koji logs.
-Ralph
On Tue, 2 Apr 2013 12:23:35 -0400 Ralph Bean rbean@redhat.com wrote:
dgilmore noted in channel that the koji fedmsg plugin is producing tracebacks like the following:
Error running postBuildStateChange callback from _koji_plugin__fedmsg-koji-plugin: Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/koji/plugin.py", line 165, in run_callbacks func(cbtype, *args, **kws) File "/usr/lib/koji-hub-plugins/fedmsg-koji-plugin.py", line 94, in send_message body = get_message_body(topic, *args, **kws) File "/usr/lib/koji-hub-plugins/fedmsg-koji-plugin.py", line 50, in get_message_body msg['owner'] = kojihub.get_user(info['owner_id'])['name'] KeyError: 'owner_id'
The error is not occurring for *all* postBuildStateChange calls, only for some. We are not sure if this has been happening since the fedmsg plugin was introduced or if it is a result of the koji upgrade that happened last night. It is not causing koji to fail, but the subset of build state change messages that hit this traceback are not being published. It is also adding noise to the koji logs.
The koji fedmsg plugin is kept in puppet, so we can patch it there (it is not in an rpm). The following patch should do the trick: http://ralph.fedorapeople.org/0001-Silence-intermittant-koji-tracebacks.patc...
For some messages, a None (null in json) will be published for the first time in the owner field. The code that parses those messages on the consuming side can be found here: http://bit.ly/16jqhtq It looks like it can handle a None without causing any further issues. I can't say for certain about any third-party code that may be listening to koji/buildsys messages and whether or not it can handle a None/null.
I'm looking for two +1s to apply the patch above to clean up the koji logs.
After quick discussion on irc
+1
But keep a close eye on what happens when None comes through - so we can have a patch quickly.
-sv
On Tue, 2 Apr 2013 12:31:43 -0400 seth vidal skvidal@fedoraproject.org wrote:
After quick discussion on irc
+1
But keep a close eye on what happens when None comes through - so we can have a patch quickly.
Agreed.
+1 here as well.
kevin
infrastructure@lists.fedoraproject.org