@Psykar Welcome to the Rockstor community.
This is a super exiting project, and thanks for building on @bigfoot90 start in this area and sharing your progress.
If this gets more traction we could consider adopting it as an official Rockstor repository. That might help to focus efforts on this particular implementation.
Of course there is the obvious fractal self hosting question of “Fancy submitting a Rock-on”, ie see our rockon-registry Readme section:
How can I add my own app?
There are a few caveats but not that since this project was started by @bigfoot90 we have since gotten the ability to pass arbitrary devices through to a rock-on, ie potentially block devices maybe. See the @Flox contribution in the above Readme of Devices object and their now merged pull request of:
Not the use it was intended for but still. @Flox, I’d be interested in your input on this ‘alternative’ use of your recently added device capability.
This might for part of how this Rockstor inception arrangement might take useful form. There are of course a few (read many) potential nightmares (multiple Rockstor’s managing a single pool = very bad) but then Rockstor is not best suited to dockerisation anyway, given it’s direct, and expected sole, block device control expectation. But it’s an interesting project.
Thanks for contributing your progress. Nice.
If you do embark on the inception Rock-on could you please give it a very large warning re catastrophic corruption potential if not allocated an otherwise un-managed block device. To be frank this is a fairly hairy project, but I don’t see, given a large warning in the description, why it shouldn’t be entertained. At least in the long run anyway. Maybe we could even scan currently installed Rock-ons for such a device mapping and block the host Rockstor from using / assessing that device. We have a role system that could effectively do that. And like wise only allow devices passed to this inception Rock-on that are not currently managed by the host Rockstor. Interesting for sure.
Lets see how this effort is received by the Rockstor community at large.
Thanks and sorted. Leap 15.1 (now in beta) dropped the firewalld package on server type installs, so noted as such in the referenced doc.
And Thanks again for considering our future base of openSUSE. At least then we will have a more viable btrfs base and potential support escalation to SUSE themselves. Both major influences in our move given that as from openSUSE Leap 15.0 there is now binary compatibility to SLES (Suse Linux Enterprise Server).