Re: [Libvir] Remote patch, 2007-02-28
Hi Rich,
I guess I never gave a real answer to this ...
On Thu, 2007-03-01 at 13:56 +0000, Richard W.M. Jones wrote:
Mark McLoughlin wrote:
> Hey,
> Btw, I'm really becoming quite convinced we'll evenutally regret using
> SunRPC if we stick with it.
Morning Mark, thanks for taking the time to look at the patch in detail.
Do you have some actual concrete problems with SunRPC? For me it solves
the problem of marshalling complicated data structures, including all
the error infrastructure, over the wire (see src/remote_rpc.x). It is
very trim and efficient. It demonstrably allows us to run over TLS,
Unix domain sockets, and ssh. It handles versioning for us.
On the other hand, coding with it is grotty to say the least.
But we definitely shouldn't publish the SunRPC interface or allow others
to interoperate with it, so that we can keep our options open in future.
So, thoughts on the SunRPC stuff:
- IMHO, we're never going to encourage people to use the SunRPC
interface directly, but at some point we may really want to expose
the remote interface directly and so we'll move to another
transport.
- I'm not sure the libvirt API is really well designed for remote
use, so I'm not sure that mapping the API calls to RPC calls is the
best approach.
e.g. to iterate over the list of domain UUIDs, you need to
ListDomains(), and then for each of them LookupByID() and
GetUUID(). That API might be fine for apps, but libvirt doesn't
necessarily need to map the API calls exactly to RPC calls - e.g.
you could have a ListDomains() RPC call return id/name/uuid tuples
and make LookupByID() and GetUUID() not involve a network
roundtrip[1].
One problem with that is that in order for the remote driver to
know when to invalidate the ListDomains() cache, it needs
asynchronous notification of domain creation. Which I think we want
in the API long term, anyway.
Maybe you could argue that all this is orthogonal to the transport
question - "XDR is just a marshaling format" - but I'm not
convinced, especially wrt. the async notification aspect. Also,
AFAIR "we can just map the library calls to RPC calls" was one of
the motivations for using SunRPC, so ...
- Yes, it's ugly code and even though you say it's done, code is
never really done. Especially here where there are lots of stuff
we're not sure we've gotten right - encryption, authentication,
mapping the library calls to RPC calls, async notification etc.
I think people might avoid hacking on this code, and that won't
help it evolve.
- Similarly, some people would consider SunRPC an old, legacy, crufty
protocol. RPC systems is one of those high-fashion areas where
people hold opinions which aren't necessarily terribly logical, and
so I think SunRPC will turn off hackers who might otherwise be
interested.
At the same time, though, I can sympathise with "look, we've written
all this code and it works fine, so let's just go with it". Perhaps
that's the right approach, and I'm just being a party pooper.
Cheers,
Mark.
[1] - Again, that's the kind of optimisation I think is really useful
rather than "SunRPC is faster then XML-RPC"