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

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.

image

@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:

If anyone is interested in testing this proposed Rock-on, or any other in our pull request queue: https://github.com/rockstor/rockon-registry/pulls take a look at the following Wiki thread in the forum:

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

Hope that helps.

1 Like

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

1 Like

@kageurufu Hello again.
Re:

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:

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.

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 :slight_smile: .

1 Like

@kageurufu Re:

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

Cheers.

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. :slight_smile:

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.

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.

2 Likes