launchpad-reviewers team mailing list archive

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

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

Description changed to:

Before we begin, please accept my apologies for the size of this branch.  I'll try to explain it in layered parts so you can treat it as such.

The first part is the Cobbler XMLRPC API: CobblerSession, the CobblerObject hierarchy, and CobblerCommands.  These wrap Cobbler's XMLRPC API in a bunch of Twisted-enabled but pseudo-synchronous classes.

What do I mean by pseudo-synchronous?  Any method annotated with @inlineCallbacks may return control to the reactor while waiting for a response.  Any such method returns a Deferred.  Any function that wants to call any of these must also use @inlineCallbacks; and because of that it must "yield" any Deferred that it gets back from function calls it makes, and it must use returnValue() rather than the "return" keyword for its return value.  Apart from that, it's a lot like synchronous programming.

CobblerSession is the class that manages basic interaction with Cobbler through XMLRPC.  It logs in, makes pseudo-synchronous calls, and if it finds that its credentials have expired, it logs in again (and retries any failing call).

CobblerObject is the base class for various types of object that Cobbler manages in its internal extensible database: systems, profiles, distros, and whatever else it may have.  They all work very much the same, so this is a little abstraction layer that hides the differences.  CobblerSystem, CobblerProfile, and so on inherit from it (and in some cases, add a few methods of their own).  Internally they all use the CobblerSession to forward requests to Cobbler.  The methods map nearly one-to-one with Cobbler's API, but we swept modification and saving of objects into a single method to simplify the API and keep transactional behaviour manageable.

And CobblerCommands?  That's really just a grab-bag for remaining methods in the Cobbler API, which didn't fit in neatly with the rest.  We may want to refine that later, or maybe not.

The second part of what this branch adds isn't really complete yet: a fake Cobbler implementation, also using a fake Twisted XMLRPC proxy, so that we can write pseudo-synchronous tests without an XMLRPC server.  It works like this: a FakeCobblerSession (it will probably move into fakecobbler.py) is basically a real CobblerSession but with the fake proxy.  The fake proxy acts as an asynchronous XMLRPC server to the session, but routes the calls to plain old synchronous methods on a FakeCobbler object.  Its python API should be identical to the real Cobbler XMLRPC API.

We can extend or instrument FakeCobbler objects to mimick the basic behaviour of a real Cobbler server.  For now it simulates nothing but simple authentication; we can add registration and management of systems and other cobbler objects later.

And that's when we can start proper testing of the CobblerObject hierarchy: register a system, modify it, look it up by name, delete it.  We should also be able to redirect most tests to a real Cobbler and get the same results.

Oh, one more thing: we'll need to get these tests running as part of bin/test.  The ongoing work on nose may help with that.


Jeroen

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