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.

_______________________________________________
Mailing list: https://launchpad.net/~launchpad-reviewers
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~launchpad-reviewers
More help   : https://help.launchpad.net/ListHelp

Reply via email to