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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
