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

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.