Hi,
I created pull request containing initial implementation of VM Monitoring and Management for Cockpit, joint effort of Martin Betak and me.
The plugin is far from being finished, but it shows main ideas regarding UI structure, transitions and code design. I'm pushing present code to hear feedback and ideas regarding UI and ongoing functional priorities.
In general, the goal is to have sort of virt-manager in Cockpit some day in the future. In the short-term, I strive for a VM monitoring and basic troubleshooting tool.
Since defining new VM is a very complex task, let's start from the VM monitoring and add VM definition afterwards.
== What Is Done Please have a look at attached screenshots.
The plugin lists VMs defined on the host. The user can see their status, basic properties and initiate basic actions (start, stop, restart). By clicking on a VM, its detail is displayed.
The VM Detail shows additional properties, actions and history charts.
The VM Detail page can be invoked via URL '.../vms#/vm/[VMNAME]', as it might be useful for embedding.
== Internals Recent implementation is based on polling of libvirt (virsh).
The plugin is open to add additional data/action providers, i.e. the oVirt is planed. On the plugin's initialization, host capabilities are checked and so the appropriate provider is selected.
Added value of the oVirt provider will be in - guest agents (monitoring and actions) - migration - performance (once the VDSM is already installed) - DBus once implemented (maybe) - access to the oVirt's engine managing whole cluster, so additional complex functionality is available and host-local changes are not in contrary to the cluster manager effort
A very first implementation was based on machined/dbus, but there was no added value, so I dropped that code.
== Code The plugin is based on React/Redux.
React-lite is being reused, since it's already part of the Cockpit's bower.json. The Redux part can become 'an example' for ongoing more complex plugins.
The Plugin follows ES6 syntax, so Babel has to be used.
In general, we can see a big benefit in use of webpack for the JavaScript in Cockpit. Anyway, we tried to keep dependencies on third-party JavaScript libraries/tools at minimum and we follow recent Cockpit build conventions.
Does it make sense for Cockpit to move to webpack? We want to check beforehand whether it's worth of making effort...
== Ongoing Work Enhance the VMs List for - charts showing actual cpu, mem, net and disk utilization - screenshot of a running VM - get console - sorting and searching - initiate VM migration (complex task, not to be implemented in the short-term) - dashboard-like view: show aggregated statistics - running VMs count - total resource consumption by VMs - button to shut down all vms (before host maintenance)
Enhance the VM Detail page for - VM's cpu, mem, net, disk utilization history charts (since plugin start) - show more VM properties - get console
Allow VM definition - since it's complex, let's start simple - wrap basic options of 'qemu-img create' and virt-install - accept copy&paste libvirt XML definition - ongoing work can concentrate on related more complex topics
Add 'oVirt' as an optional provider - use VDSM if running on the host - use oVirt engine if accessible (add SSO or login form) - leverage VM definition, migration and complex configuration
== How to play I've updated the Vagrantfile to allow nested virtualization for libvirt. The qemu and libvirt are added to the 'dnf install'.
As mentioned above, recently the plugin does not support new VM definition. To add a testing nested-vm, you can: $ sudo vagrant ssh
In the vagrant: $ sudo su $ cd /tmp $ NAME=subVmTest1 && qemu-img create -f qcow2 ${NAME}.img 256M && virt-install -r 128 --pxe --force --nographics --noautoconsole -f ${NAME}.img -n ${NAME}
Log into Cockpit as the 'root' user (pwd 'foobar').
Please note, the created VM is for vms plugin testing only, it provides no real OS. It's purpose is 'just to be listed by the libvirt'.
-- Marek
Hey,
Wow, great work!
On Wed, May 18, 2016, at 14:16, Marek Libra wrote:
The Plugin follows ES6 syntax, so Babel has to be used.
We've refrained from using babel so far, because it adds 50 MB to cockpit's source tarball. (We're shipping all dependencies.)
We'll need to find a solution to this this at some point though, because react-tools (which we use to transpile jsx) is deprecated in favor of babel[1].
In general, we can see a big benefit in use of webpack for the JavaScript in Cockpit. Anyway, we tried to keep dependencies on third-party JavaScript libraries/tools at minimum and we follow recent Cockpit build conventions.
Does it make sense for Cockpit to move to webpack? We want to check beforehand whether it's worth of making effort...
Yes, it does. In fact, I'm researching moving the current modules to webpack right now.
We want to stabilize the API in cockpit.js and allow for external components. The idea is that components ship whatever libraries they need in their bundle. This way, we don't need to add all dependencies to cockpit itself. We only want to promote stuff into the base bundle when multiple components use it. For example, we might include some commonly used react components in there at some point.
Would you be ok with waiting for a bit until we have a story for external modules and then be the first one?
Sorry that I don't have comments on the actual component yet ;)
Regards Lars
[1] https://facebook.github.io/react/blog/2015/06/12/deprecating-jstransform-and...
----- Original Message -----
From: "Lars Uebernickel" lars@uebernic.de To: "Development discussion for the Cockpit Project" cockpit-devel@lists.fedorahosted.org Cc: "Martin Betak" mbetak@redhat.com Sent: Wednesday, May 18, 2016 11:23:38 PM Subject: Re: VM Management - initial pull request
Hey,
Wow, great work!
On Wed, May 18, 2016, at 14:16, Marek Libra wrote:
The Plugin follows ES6 syntax, so Babel has to be used.
We've refrained from using babel so far, because it adds 50 MB to cockpit's source tarball. (We're shipping all dependencies.)
We'll need to find a solution to this this at some point though, because react-tools (which we use to transpile jsx) is deprecated in favor of babel[1].
IIUC, this shipping of both runtime and build dependencies in the tarball is because of build isolation, so they do not need to download any external library. If so, a solution to this might be in introduction of "wrapping" rpms containing a bunch of JS libraries covering multiple project needs. Please have a look at http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc23/x86_64/ovirt-e... or http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc23/x86_64/ovirt-e...
So we do not need to worry about tarball size and repeatable check of licenses.
In general, we can see a big benefit in use of webpack for the JavaScript in Cockpit. Anyway, we tried to keep dependencies on third-party JavaScript libraries/tools at minimum and we follow recent Cockpit build conventions.
Does it make sense for Cockpit to move to webpack? We want to check beforehand whether it's worth of making effort...
Yes, it does. In fact, I'm researching moving the current modules to webpack right now.
We want to stabilize the API in cockpit.js and allow for external components. The idea is that components ship whatever libraries they need in their bundle. This way, we don't need to add all dependencies to cockpit itself. We only want to promote stuff into the base bundle when multiple components use it. For example, we might include some commonly used react components in there at some point.
Would you be ok with waiting for a bit until we have a story for external modules and then be the first one?
That would be great approach to give each module freedom of choice. For sure, I'm open to be a pioneer once this is ready, it will certainly untie hands to all modules.
If the overall comments on the plugin are ok, I will be happy to spend more effort on ongoing implementation. So from my perspective, I would prefer to convergate to a merge and stack ongoing smaller patches on top of it, incl. adaptation to the new "module" approach. It will assure me in the direction.
Sorry that I don't have comments on the actual component yet ;)
Regards Lars
[1] https://facebook.github.io/react/blog/2015/06/12/deprecating-jstransform-and... _______________________________________________ cockpit-devel mailing list cockpit-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted....
cockpit-devel@lists.fedorahosted.org
-
Lars Uebernickel -
Marek Libra