[libvirt] Remotable Libvirt

[Stef Walter]

On 07.06.2017 11:02, Daniel P. Berrange wrote:
> On Wed, Jun 07, 2017 at 10:47:25AM +0200, Stef Walter wrote:
>> On 07.06.2017 07:49, Martin Pitt wrote:
>>> Hello Richard,
>>>
>>> Richard W.M. Jones [2017-05-31 18:00 +0100]:
>>>> I agree with others that as things stand you will need a REST or DBus
>>>> or similar API added to libvirt.
>>>>
>>>> However have you considered using gobject-introspection to generate
>>>> new "Payload" types automatically?
>>>
>>> This doesn't fundamentally change the picture here. Our JavaScript runs in the
>>> browser, so on that side GI doesn't help. What we could do is to dynamically
>>> create some code in the Cockpit module, send it over to the remote machine, and
>>> have it be executed. This could be in Python, which then assumes that
>>> python-libvirt is installed there, or in JS which then assumes that
>>> libvirt-glib and gjs are installed. The latter seems like a stronger
>>> assumption on a server even, but structurally these are pretty similiar.
>>>
>>> I. e. GI is not a magic thing to make an API remotable, it just makes it
>>> bindable to different programming languages.
>>>
>>> C/GI interfaces also don't map well to D-Bus, i. e. it's not practical to
>>> autogenerate a D-Bus interface for a given GI API. This still works for the
>>> most simple methods that only accept primitive data types and strings, but as
>>> soon as you pass any structs, pointers, function pointers etc. around this
>>> can't be exposed though D-Bus any more without further interpretation on the
>>> server side.
>>
>> Perhaps not an runtime. But it seems like such a thing could be done at
>> compile time for the libvirt C API. The libvirt folks do it for their
>> python bindings, using code generation.
>>
>> The libvirt Python API behaves a lot like the C API. It's very flat and
>> not very "pythonic". Which is actually a nice target for us. We could do
>> something similar with a simple "flat" DBus wrapper of the API ... using
>> code generation.
> 
> I see no problem with mapping almost all of the libvirt API into DBus, as
> the DBus method call + signal concepts are very similar to the libvirt RPC
> call and event concepts.  The place where you would have trouble mapping
> to DBus is the stream support as that has no equivalent in DBus, and there's
> no efficient workaround to deal with it that I can imagine. 

Good to know.

FWIW, DBus supports FD passing. And Cockpit supports FD passing over DBus:

https://github.com/cockpit-project/cockpit/pull/5992

But I agree that any such wrapping of libvirt APIs involving streaming
in DBus FD passing would probably wouldn't be auto-generated.

Cheers,

Stef

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 205 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170607/8ef61dcf/attachment-0001.sig>