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 problem(s) > > ============== > > > > > > > As mentioned earlier, if an application is only concerned with managing of KVM > > (or other stateful drivers running inside libvirtd), we have scope to be able to > > expose a fully asynchronous management API to applications. Such an undertaking > > would effectively mean creating an entirely new libvirt client library, to expose > > the asynchronous design, and we obvious have to keep the current library around > > long term regardless. Creating a new library would also involve creating new > > language bindings, which just adds to the work. Rather than undertake this > > massive amount of extra work, I think it is worth considering declaring the RPC > > protocol to be a fully supported interface for applications to consume. > > I don't think this a good idea. NB, docs declaring this supported were already acked & merged: https://libvirt.org/support.html#rpcproto > > There are > > already projects which are re-implemented the libvirt client API directly ontop > > of the RPC protocol, bypassing libvirt.so. We have always strongly discouraged > > this, but none the less it has happened. As we have to maintain strong protocol > > compatibility on the RPC layer, it is effectively a stable API already. > > And we discourage that for a reason. For instance, our client library > does some checks before anything hits the RPC layer, or sets up a state > (remoteAuthSASL()). Also, the client library encapsulates two or more > calls into a single function: remoteDomainCreate() for instance. Nothing in the server can rely on the client library performing checkins before the RPC is sent, so those client side checks are at best an optimization to get quicker / clearer error message. An alternative impl would of course need to implement SASL / TLS in the compatible manner. 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. 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
