Bug 1416814 - XML-RPC fault: <type 'exceptions.TypeError'>:to_xml() takes at most 4 arguments (5 given)
Summary: XML-RPC fault: <type 'exceptions.TypeError'>:to_xml() takes at most 4 argumen...
Alias: None
Product: Beaker
Classification: Community
Component: command line
Version: 24
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: beaker-dev-list
QA Contact: tools-bugs
: 1419935 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-01-26 14:13 UTC by Martin Cermak
Modified: 2017-02-24 13:57 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-02-23 15:18:37 UTC

Attachments (Terms of Use)

Description Martin Cermak 2017-01-26 14:13:12 UTC
Hi guys,

with updated rhel-7.3 system, I'm hitting this:

$ bkr job-results J:1687827
XML-RPC fault: <type 'exceptions.TypeError'>:to_xml() takes at
most 4 arguments (5 given)

My system has beaker-client-24.0-1.el7sed.noarch taken from
baseurl=http://download.lab.bos.redhat.com/beakerrepos/client/RedHatEnterpriseLinux$releasever/ [Open URL]

Downgrading to beaker-client-23.3-1 fixes the problem for me.

The problem happens in beaker-client-24.0-1.el7sed at:

82 try:
83 return cmd.run(*cmd_args, **cmd_opts.__dict__)
84 except krbV.Krb5Error, e:


Comment 1 matt jia 2017-02-02 01:16:51 UTC
This issue will be resolved after upgrading the beaker production server to beaker 24.0. I have tried running this command against the beaker-devel which has been upgraded to 24.0 with no issue.

Comment 2 Dan Callaghan 2017-02-23 15:18:37 UTC
So this was only a problem when running bkr client 24.0 against an older server. There was a period of a few weeks between when the 24.0 release was published upstream (and in our internal yum repos) and when our main production Beaker server was upgraded to 24.0.

Normally we are supposed to preserve backwards compatibility in the client for talking to older servers, for this exact reason.


This bug was just an accidental incompatibility which we introduced, by passing an additional parameter on an existing XMLRPC method. The older version of the XMLRPC method did not accept the new parameter.

Unfortunately there is no particularly nice way to handle that situation, so it's hard to say what we could have done better. Introducing a new XMLRPC method with the extra parameter (or better, switching to a new JSON API) would have broken backwards compatibility with older servers just the same.

We could consider updating the server to accept and discard *args on all XMLRPC methods but I am not sure it's wise to do that in the general case, and I would rather just focus on moving to JSON APIs instead.

So I am going to close this as WONTFIX, now that our main production Beaker server is upgraded this problem shouldn't be affecting anyone anymore.

Comment 3 Dan Callaghan 2017-02-23 15:18:49 UTC
*** Bug 1419935 has been marked as a duplicate of this bug. ***

Comment 4 Martin Cermak 2017-02-23 16:02:24 UTC
The only issue about this (from my persp) is, that a "testing" version of beaker-client.rpm leaked into the "stable" yum repository at some point.  This would be good to avoid in the future.  Thanks, guys.

Comment 5 Dan Callaghan 2017-02-23 20:41:54 UTC
That sounds bad... Do you know exactly which version, and which repo? Roughly when did you see it? I can try and track down what went wrong.

Comment 6 Martin Cermak 2017-02-23 21:12:35 UTC
See the bug description:

> My system has beaker-client-24.0-1.el7sed.noarch taken from
> baseurl=http://download.lab.bos.redhat.com/beakerrepos/client/
> RedHatEnterpriseLinux$releasever/

I've been hitting this one day before I filed this bug, which is 2017-01-25.

Comment 7 Dan Callaghan 2017-02-24 10:47:48 UTC
(In reply to Martin Cermak from comment #6)

That's expected though. beaker-client-24.0-1.el7sed is not a testing build, it is the final release of 24.0 which we released on 25 Jan.

As mentioned above, the issue is just that there is (always, unavoidably) some delay between when we publish Beaker releases and when they get deployed on our production server.

Comment 8 Martin Cermak 2017-02-24 13:57:12 UTC
Understood.  Thanks.

Note You need to log in before you can comment on or make changes to this bug.