[Libvir] Remote patch, 2007-02-28

[Mark McLoughlin]

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"