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

[Anthony Liguori <aliguori@xxxxxxxxxx>]

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?
Regards,

Anthony Liguori
> >              sys.exit(1)
> >          except:
> >              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.
>
> Cheers,
>
> Ewan.
>   
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel