Re: Remotable Libvirt

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

 



On 05/31/2017 01:00 PM, Richard W.M. Jones wrote:
> On Wed, May 31, 2017 at 09:22:41AM -0700, Peter wrote:
>> The javascript is always run in the users browser. The dbus calls or
>> system commands are sent by the javascript via a websocket to
>> cockpit-ws. It then forwards those messages on to the correct
>> cockpit-bridge. Based on the payload the bridge knows how
>> communicate with the appropriate system API. (See https://github.com/cockpit-project/cockpit/blob/master/doc/protocol.md
>> or run 'cockpit-bridge --version' for a list).
>>
>> So in keeping with the cockpit ideals cockpit-bridge should not know
>> how to start a virtual machine or link to the libvirt library. It
>> should receive a payload that when properly executed by the bridge
>> results in the machine starting. Right now this is only possible
>> using the virsh type commands that have the problems discussed
>> earlier. I think it's clear that the existing RPC is not an option.
>> So that pretty much leaves us with the choice to roll or own
>> solution or to add a more generic dbus or rest wrapper for libvirt.
> 
> Thanks - that's a bit clearer now.
> 
> I agree with others that as things stand you will need a REST or DBus
> or similar API added to libvirt.
> 

One thing to consider though is that the libvirt API is only part of the
equation. The biggest part for sure, but if cockpit wants to create and manage
libvirt XML it should eventually use libvirt-gconfig, which is just a
standalone bit of code for manipulating the XML, and possibly libosinfo and
other libvirt-* libraries. Dan's writeup here describes the idea behind the
different libraries:

https://www.berrange.com/posts/2011/11/22/introducing-the-libvirt-glib-a-mapping-of-the-libvirt-api-and-xml-to-glibgobject/
https://www.redhat.com/archives/libvir-list/2012-September/msg00325.html

Though the only ones that have had any real development live in
libvirt-glib.git: libvirt-glib, libvirt-gconfig, libvirt-gobject. And they
would likely need to be extended to fit cockpit's goals, but it's better than
writing all that XML building from scratch.

> However have you considered using gobject-introspection to generate
> new "Payload" types automatically?
> 
This is an interesting idea (though I have no clue if it's technically
feasible). But if it worked it could be used to cover
libvirt-{gobject,glib,gconfig} and libosinfo which is likely everything
cockpit will ever need for virt management.

- Cole

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux