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 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
On Thu, Nov 23, 2017 at 11:32:19AM +0100, Michal Privoznik wrote: 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 :|