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 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 Oh, how did that one slipped in? :-) > > >>> 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. Sure. Receiver (=server) has to do the checks itself. > > 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. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
