[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Remotable Libvirt



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

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.

Cheers,

Stef

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]