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

Re: [libvirt] Remotable Libvirt

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?


They should be usable from Javascript directly, as in the .js example


They're usable from a standalone javascript interpretor, but there's no
way to use them from a client side javascript interpretor in the user's
web browser.

Hmm OK, I thought "implemented in javascript" meant they were using
server-side Javascript.

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?
Where does the Javascript run?  What JS engine runs it?


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
> javascript. There is no cockpit backend that knows how to change a
> hostname for example. The cockpit backend knows how to handle a dbus
> payload. The javascript running in the users browser knows how to use
> the systemd dbus API at org.freedesktop.hostname1 to manage the
> system hostname.

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.

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