Rock-on provided panels, integrated into the main Rockstor WebUI

[kageurufu (Frank)]

I’m working on a custom Rock-on for libvirt and virt-manager, exposing a HTML5 view of virt-manager for management for now.

It would be nice to allow a Rock-on to list that the configured UI port is frame-embeddable, and add it somewhere to the main Rockstor UI tabs, maybe as a dropdown under Rock-ons.

[phillxnet (Philip Guyton)]

@kageurufu Hello again. Libvirtd / VMM look-a-like within a Rock-on is very interesting. Not sure I like the dynamic extension of the Web-UI to contain arbitrary Rock-on Web-UI’s though.

Just popping in here to link back to your pending review/comment Rock-on pull request here:

https://github.com/rockstor/rockon-registry/pull/292

If anyone is interested in testing this proposed Rock-on, or any other in our pull request queue: Pull requests · rockstor/rockon-registry · GitHub take a look at the following Wiki thread in the forum:

How to test a Rock-on pull request

This wiki entry is intended as a overview of the process required to test a proposed Rock-on; ie one that currently exists within a GitHub Pull request. Please edit with care as you see fit as this wiki guide, like the rest of Rockstor, is a community focused effort. Comments should be constrained to content suggestions only. Thanks. Rockstor’s Rock-on registry / repositor is almost entirely contributor populated and by way of due diligence each submission (pull request in GitHub speak) require…

Note that @kageurufu now has 3 pending Rock-ons in need of a review. Just saying .

Hope that helps.

[kageurufu (Frank)]

So, in further testing, I feel like libvirtd inside docker isn’t ideal for quite a few reasons.

Other than libvirt creating a default subvolume at /var/lib/libvirt, enabling it on the host shouldn’t cause any other problems. Would you be open to discussing enabling libvirtd by default in Rockstor 4?

I personally feel like some sort of libvirtd/kvm integration, even if its just listing “libvirtd” under services, and commenting that a rock-on can provide interfaces for it. This would be a huge benefit for Rockstor in general, in my mind.

EDIT: For investigative purposes, this adds about 70MB to the ISO size

[phillxnet (Philip Guyton)]

@kageurufu Hello again.
Re:

Would you be open to discussing enabling libvirtd by default in Rockstor 4?

Yes, of course. But not in v4 I think. We are about to go stable (RC9) but directly upon our starting a new testing branch (branch based this time) the:

… listing “libvirtd” under services, and commenting that a rock-on can provide interfaces for it.

would be a very welcome pull request set: added packages/services to rockstor-installer (testing-branch pending), potential change in default systemd service setting via the systemd-presets-branding-rockstor package (https://build.opensuse.org/package/show/home:rockstor:branches:Base:System/systemd-presets-branding-rockstor) and of course the changes in rockstor-core.

The pending testing branch is ear-marked for the next stable release which will be when our soon-to-be testing branch becomes usable and relatively stable again.

EDIT: For investigative purposes, this adds about 70MB to the ISO size

Thanks, good to know. Yes we need to setup our back-end for testing branch capability on the installer repo as of yet. But have recently added the ability to do pr based installer builds so getting there.

Thanks for the update. It’s quite the pending potential feature. I’m super keen for Rockstor to not become everything and the kitchen sink and we are not, and would be wise to not even try to be Proxmox as well as what we are. Proxmox is what it is, we are primarily a NAS with services. But as you say an additional service for advanced Rock-on options may be a step far enough for those who fancy having just that little bit extra to what we have already.

@Flox’s Input on this idea (as time permits) would be good; as always.

Thanks again for the update and let us know how you get on with further researching this more mid-term potential scope creep .

[phillxnet (Philip Guyton)]

@kageurufu Re:

EDIT: For investigative purposes, this adds about 70MB to the ISO size

and what is the resulting instantiated install size increase, out of interest?

Cheers.

[DrC (Cam)]

Currently rockstor supports downloading docker images, which is ace. But some ‘things’ (nfsd, libvirt) dont like running inside docker images and want raw metal.

Working on my ‘just say the idea, even if it sounds stupid’ mind set…

A more hairy proposition would be to consider having ‘apps’ for stuff that cant run inside docker images. So one could ‘hack’ these to work with a btrfs file system. Eg, install libvirt app, give it a filesystem to be contained in (100% nothing in root) and run out of via a similar UI that you have for installing docker images.

So:

• download libvirt
• config window asks you for all the variables you need (installs all its bits in there and makes a directory for each VM which holds config, block files for filesystems etc)
  Easy to remove… just nuke the share you setup in the config window when you uninstall it (maybe ask first… haha)

Ive been pondering the idea of stripping things out of ‘core’ rockstor and making them plugins so you just end up with a skeleton and you can install samba (works in docker), nfsd (doesnt work in docker) as addons. I wonder how ‘thin’ you could get it. Rockstor would be an installer and provide gui/config services.

[kageurufu (Frank)]

A more hairy proposition would be to consider having ‘apps’ for stuff that cant run inside docker images. So one could ‘hack’ these to work with a btrfs file system. Eg, install libvirt app, give it a filesystem to be contained in (100% nothing in root) and run out of via a similar UI that you have for installing docker images.

So:

• download libvirt

My prototype has libvirtd inside docker, but the file browsers are all useless because the containers don’t have the same filesystem, you have to mount the same volumes to both to get anything to work right. I’m still experimenting with all the options there.

and what is the resulting instantiated install size increase, out of interest?

I can install both in VMs later to test, would be good to make sure it has all the right dependencies for libvirt.
There may be an issue using opensuse’s libvirtd with networkmanager, its compiled with an explicit wicked dependency.