launchpad-reviewers team mailing list archive

["Jeroen T. Vermeulen" <jtv@xxxxxxxxxxxxx>]

The proposal to merge lp:~jtv/maas/cobbler-exception into lp:maas has been updated.

Description changed to:

This branch parses Cobbler exceptions into more meaningful ProvisioningError exceptions.  Both are derived from xmlrpclib.Fault and so contain a numerical faultCode as well as an error text.  But ProvisioningError has more detailed faultCode numbers.  If we need to distinguish more kinds of Cobbler exceptions, we can extend the enum that specifies these error codes (PSERV_FAULT) and extend the parsing code that figures out the Cobbler exception.  It's a bit hackish, but that's what you get for trying to deal with Cobbler.

A note on xmlrpc and type information.  Cobbler likes to raise an exception called CX, which has no faultCode but arrives at pserv (on the other side of the xmlrpc interface) in the form of an xmlrpclib Fault anyway.  The faultCode is simply always 1.

Something similar will happen to ProvisioningError: maasserver won't see it as its own type of exception, and so won't be able to handle it as such.  But ProvisioningError provides a meaningful Fault code, and maasserver can differentiate its handling of the exception based on that code.

I had originally designed this as a context manager, called CobblerCatcher.  According to the PEP for context managers, however, raising an exception from __exit__ is the wrong thing to do.  The current documentation actually only says that it's bad to re-raise exc_val, but better safe than sorry.

(Tests for this also pass against vdenv)

For more details, see:
https://code.launchpad.net/~jtv/maas/cobbler-exception/+merge/98148
-- 
https://code.launchpad.net/~jtv/maas/cobbler-exception/+merge/98148
Your team Launchpad code reviewers is requested to review the proposed merge of lp:~jtv/maas/cobbler-exception into lp:maas.