[libvirt] Redesigning Libvirt: Better supporting non-hypervisor agnostic concepts

[Daniel P. Berrange]

On Thu, Nov 23, 2017 at 04:58:55PM +0100, Michal Privoznik wrote:
> On 11/23/2017 11:42 AM, Daniel P. Berrange wrote:
> > On Thu, Nov 23, 2017 at 11:32:19AM +0100, Michal Privoznik wrote:
> >> On 11/14/2017 06:25 PM, Daniel P. Berrange wrote:
> > The remoteDomainCreate() impl was a hack, because we forgot that we
> > needed to update the virDomainPtr with the ID value. An implementing
> > the client directly will not have any virDomainPtr object to update.
> > They'll have their own concept there, which may not even care about
> > having an ID value cached locally - I certainly wouldn't bother if
> > we wrote libvirt again - using the UUID exclusively is a much better
> > choice. So they need not have multiple RPC calls in the same place.
> > On the other hand, since the app is not constrained by the need to
> > follow the libvirt public client API, then may well write their
> > client impl in a manner that doesn't have a 1-1 mapping to RPC
> > messages - the 1-1 mapping is merely how we chose todo it for libvirt.so.
> > They could write something higher level that triggers many RPC calls for
> > one application call if they so desire.
> 
> Okay. Makes sense. But just to be clear - we will expose our *public*
> RPC (which can be mapped onto our public APIs), but NOT expose our
> *private* RPC which is the one used to communicate between two daemons
> (say virthypervisord and virnetworkd), right? Moreover, if we require
> all the daemons to be the same version we can consider the private RPC
> unstable and we can change it as we please. E.g. virthypervisord calls a
> function from virstoraged to determine blocking chain. If we need to add
> a new argument, we can just change the RPC instead of introducing new v2
> of the call.

Agreed, I would only want our primary RPC protocol considered supported,
Never any of the inter-daemon communiction protocols, which should remain
subject to change - this is another good reason to only ever support UNIX
domain sockets in these modular daemons - explicitly means we don't have
to care about compat across libvirt versions.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|