[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [RFC] Xend XML-RPC Refactoring

Hi Ewan,

I've made the changes you've requested except where I've described below. After all the regressions complete, I'll push it out to the list (sometime tomorrow as long as nothing fails miserably).

Ewan Mellor wrote:
This is all a bit skanky, and could be easily cleaned up by introducing a
naming convention for XendDomain, XendNode, etc.  How about if we prefixed
every function that we wish to expose to the messaging layer with
"public_"?  So for example XendDomainInfo.send_sysrq would be named
public_send_sysrq instead.  Then, we could use that to guide the
function registration, rather than having exclude lists and inline lists
of callable methods.
I went ahead and started using the public_ naming convention for XendDomainInfo. It was fine for a couple of the methods but it got ugly real quick for things like deviceDestroy as it's called in a bunch of other places within Xend.

So, I've got two possible solutions for this. We could just keep the white list or we could introduce new public_ methods within XendDomainInfo that were just simple wrappers for the underlying methods. It's seems a bit unnatural but less unnatural than peppering calls to public_ functions through Xend. Thoughts?
I can see why you've done this, but it just led me to wonder why
XendDomain.domain_destroy exists at all.  All it's doing is looking up a
domain ID, checking that it's not the privileged domain (in the wrong
order!) calling XendDomainInfo.destroy, and calling xc.domain_destroy in
the case of an exception.  We should move the check and the exception
handling into XendDomainInfo.destroy, and then we can dispatch to that
method straight away, without needing XendDomain.domain_destroy at all.
The messaging layer already has the capability to lookup domain IDs --
we should use it.
I've gone through and made sure that all XendDomain functions can accept either domids or names so that effectively takes care of this hack. I didn't refactor away the domain_destroy function though as it seems independent of the XML-RPC stuff.
I expect we can do better than just printing "Internal Xend Error".  How
much structure and useful information is there in an xmlrpclib.Fault at
the moment?
This one is a bit tricky. We use faultCode to encode particular exception types but I'm not sure what that buys us. I don't think encoding OSError as a faultCode (which is what I think the most common exception we toss other than XendError) really buys us much right now. I think what we need to do is audit the methods in Xend, figure out what the common errors are, *catch them within Xend*, and then rethrow them as standardized Faults. Thoughts?


Anthony Liguori
             print "Unexpected error:", sys.exc_info()[0]

Looks like that's it!  Thanks for all your hard work, Anthony, this is
going to make a big difference to Xend's usefulness and maintainability,
and you've done a good job of it.  Let's get it into 3.0.2.



Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.