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

[Michal Privoznik]

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.

> 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.

Michal