On 06.06.2017 12:13, Daniel P. Berrange wrote: > On Tue, Jun 06, 2017 at 06:07:21PM +0200, Stef Walter wrote: >> On 06.06.2017 17:17, Daniel P. Berrange wrote: >>> On Tue, Jun 06, 2017 at 05:11:55PM +0200, Peter Krempa wrote: >>>> On Tue, Jun 06, 2017 at 07:45:10 -0700, Peter wrote: >>>>> On 05/26/2017 02:11 AM, Martin Kletzander wrote: >>>>>> On Thu, May 25, 2017 at 10:16:26AM -0700, Peter Volpe wrote: >>>> >>>> [...] >>>> >>>>>> If we standardize even the smallest part of the RPC, then it might screw >>>>>> us immediately. We are keeping it private just so we can enhance the >>>>>> APIs we already have. We don't know when we will need to change some >>>>>> part of it. >>>>>> >>>>> >>>>> How does the current ssh implementation work? >>>>> (https://libvirt.org/remote.html) If clients are able to talk to a remote >>>>> libvirtd via ssh then there must be some sort of compatibility guarantee. >>>>> Otherwise unless the versions are exactly the same clients wouldn't be able >>>>> to talk to remote daemons. >>>> >>>> They use the internal RPC protocol transported over SSH. The client >>>> library initializes the ssh connection to the server, and then starts to >>>> talk the RPC tunelled over the SSH session. >>>> >>>> The compatibility is guaranteed only if you use the client library. As >>>> said, the RPC protocol is considered an internal detail and the client >>>> library shields you from a possible incompatibility if we'd ever make >>>> incompatible change. >>> >>> Ignoring wire compatibility questions, it is important to note that not all >>> functionality in libvirt is done in libvirtd. There are libvirt drivers that >>> are entirely implemented in the library, not libvirtd. For some of the >>> libvirt drivers that do use libvirtd, there is also still some functionality >>> that is client side. >> >> So to summarize what I'm hearing here: >> >> * There is no libvirt remotable API today. > > Libvirt drivers that are implemented in libvirtd are accessible remotely > using the libvirt client library. We just consider the wire protocol a > private impl detail between them. Drivers implemented outside libvirtd > are often accessible remotely too, via the hypervisor's native remoting > system. I believe those are implementation details, not and remoteable API. Libvirt and its API must always be used in process today? Even though it RPC may be in play, it is an implementation detail, not API. Correct? >> * All libvirt APIs are only able to be used in-process. >> * There is presently no ability for a libvirt API to be used from a >> browser, or non-Linux process or non-Linux system. > > Actually libvirt can be built on OS-X, Windows and FreeBSD too. Ah good to know. But the API is always used in process, correct? >> In order for Cockpit to interact with libvirt, it would need to grow a >> remoteable API. The Cockpit project could likely jumpstart such an >> effort, by lightly wrapping the C API in DBus ... and contribute that >> remoteable API code to the libvirt project. > > FWIW, if someone does want to build a DBus wrapper around libvirt, that > would be something todo as a separate code module above the libvirt > API. We would be happy to host such an effort on libvirt.org git though, > alongside other higher level API wrappers. Likewise for a REST API wrapper. This would be a useful division of labor between Cockpit consuming such a remotable API ... and the remoteable API being hosted and maintained by the libvirt folks ... although the Cockpit project could help get it started. Stef -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
