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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
