On Sat, Mar 11, 2006 at 08:55:10PM +0000, Ewan Mellor wrote:
> Anthony, I've reviewed your XML-RPC patches. It all looks good, so I'm in
> favour of putting them in straight away. I'd like to get the second patch in
> straight away as well as the first, that is (for those watching at home) to
> change xm to using XML-RPC, because I would like to deprecate the old
> protocol sooner, rather than later. Making the XML-RPC interface the primary
> control path for Xen 3.0.2 will encourage third-parties to code to that rather
> than to the s-expression protocol, and that's a good thing.
+1 we will try to switch ASAP too at the libvirt level.
> It would be prudent to make it possible to turn the XMLRPCServer off, just as
> we
> can turn the other servers off.
Big dilemna :-)
Currently with http on anybody can manipulate any Xen instance as soon
as one has Xen0 access (I run my libvirt regression test from my normal
user login but except for the convenience it's a bit scary :-). I assume
It will be exactly the same with XML-RPC. I would feel way better if we
could have a policy model which is not all on or all off implemented,
for example associating users with domains, and controlling per user
resource usage. I know that the obvious answer would be "only root should
do that" except that a frustated user needing his VM could then launch
a qemu instance instead and that wouldn't be any better for the server.
IMHO a smarter, more fine grained approach is needed, it will also require
authentication at connection time to the service, and even if not trivial
this should be doable and we use authenticated XML-RPC call all the time
for the Red Hat Network framework, so this has to be possible locally and
remotely.
> > diff -r c369d960f96b -r 095ac0d95d9c tools/python/xen/util/xmlrpclib2.py
> > --- /dev/null Tue Feb 28 16:45:20 2006
> > +++ b/tools/python/xen/util/xmlrpclib2.py Tue Feb 28 22:08:47 2006
> >
> > [Snip lots]
> >
> > +class ServerProxy(xmlrpclib.ServerProxy):
> > + def __init__(self, uri, transport=None, encoding=None, verbose=0,
> > + allow_none=1):
> > + if transport == None:
> > + protocol = uri.split(':')[0]
> > + if protocol == 'httpu':
> > + uri = 'http:' + ':'.join(uri.split(':')[1:])
> > + transport = UnixTransport()
>
> How about
>
> (protocol, rest) = uri.split(':', 1)
> if protocol == 'httpu':
> uri = 'http:' + rest
> transport = UnixTransport()
hum, do we really need to invent a new transport for local access ?
I don't remember seeing 'httpu' anywhere, sounds weird to me
[...]
> > except SystemExit:
> > + sys.exit(1)
> > + except xmlrpclib.Fault, ex:
> > +# print "Xend generated an internal fault:"
> > +# sys.stderr.write(ex.faultString)
> > +# sys.exit(1)
> > + print "Error: Internal Xend error"
>
> 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?
Another good question, as we are defining an API to Xend I think
the error handling question will become more and more important. The client
will need more structure and informations about processing error, the
full stack trace within xend might not be that useful (except for low level
debugging) to the clients, but currently I just extract a string like
"No such domain test"
which is a bit hard to process correctly even in context. A list of predefined
error code and meaning could help quite a bit along with just the error message.
> > 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.
Yup, thanks Anthony :-) !
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home