[Libvir] Remote patch, 2007-02-28

[Richard W.M. Jones]

Mark McLoughlin wrote:
>   - 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.

The level that is right for abstraction is definitely troubling to me.

For example at the moment it'll work provided that the calls in 
libvirt.c map directly on to driver calls.  In other words, with a 
unified Xen driver, if the functions in libvirt.c turn into:

   int
   virConnectGetVersion(virConnectPtr conn, unsigned long *hvVer)
   {
     return conn->driver->version (conn, hvVer);
   }

(I've removed some error checking, but that's not material).  And that 
is kind of what happens at the moment, for most of the functions in 
libvirt.c

With this scenario, it seems reasonable to abstract at the driver level, 
which is what the remote patch does right now.  We can also optimise 
calls like ListDomains so that they optimistically pull all the data 
over the wire that is needed for subsequent LookupByID calls.

This becomes problematic if the functions in libvirt.c become more 
complicated -- for example if a single function maps to several 
underlying driver calls (and I haven't really started to look at the 
networking code).

>     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.

Agreed.

Rich.