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
>>> 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=d63d5964b...
>
> 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.