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
