[libvirt] Remotable Libvirt

[Peter]

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
>>>> javascript.
>>>
>>> How about using the gobject libvirt bindings?
>>>
>>>   https://libvirt.org/git/?p=libvirt-glib.git;a=summary
>>>
>>> They should be usable from Javascript directly, as in the .js example
>>> here:
>>>
>>>   https://libvirt.org/git/?p=libvirt-glib.git;a=tree;f=examples;h=d63d5964be2299b62140f9fd183b5cc744837d8a;hb=HEAD
>>
>> 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
> ssh-agent).
>
> 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?
>
> Rich.
>

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.