On 05/31/2017 08:52 AM, Richard W.M. Jones wrote:
On Wed, May 31, 2017 at 04:02:42PM +0100, Daniel P. Berrange wrote:
> On Wed, May 31, 2017 at 03:59:10PM +0100, Richard W.M. Jones wrote:
>> On Thu, May 25, 2017 at 10:26:47AM -0700, Peter wrote:
>>> The majority of cockpit is implemented in
>> How about using the gobject libvirt bindings?
> web browser.
I see that cockpit runs two processes on the server (cockpit-ws and
I had a look at one of the modules in the source (pkg/systemd). It's
running local commands (eg. "grep"), and issuing dbus calls which
AFAIK cannot be issued over the network.
Can Peter explain a bit more about the architecture of Cockpit?
See this paragraph from my original message.
As a quick overview, cockpit aims to talk to existing remotable
system APIs. Usually these API’s take the form of dbus, REST or
executable commands. The majority of cockpit is implemented in
hostname for example. The cockpit backend knows how to handle a dbus
the systemd dbus API at org.freedesktop.hostname1 to manage the
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
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.