This is a high level design notes and RFC type post. Feel free to provide feedback.
The current implementation of the Rock-on framework is simple and works for the most part. Judging from user feedback and download numbers, it’s definitely a hit. But there are some limitations
Install wizard expects users to create Shares separately which is confusing some users. It would be nice if Share creation is part of it.
Unnecessary input is requested from users such as internal db user/passwords, config Shares etc… which can be randomly generated or done properly on user’s behalf.
Rock-on submission process is not well defined. Docker image providers(I am talking to you linuxserver.io) cannot easily submit new Rock-ons. It will be nice if there was a app store that accepts submissions.
There is no generic Docker orchestration layer for power users to run arbitrary containers.
There is hardly any information about available Rock-ons consolidated in one place. An app store like web app can solve this problem.
The current UI layout clutters the display if there are a lot more Rock-ons.
In order to address above limitations, we’ll improve the current implementation in the following ways
Provide a Rock-on store/registry with browsable and searchable listing.
Provide a simple Rock-on submission interface for providers like linuxserver.io
Simplify the install wizard(fewer inputs) and integrate Share creation into it.
Update the Rock-on root Share layout so all configs can be supplied by it. And perhaps other settings; suggestions anyone?
Improve the UI layout for categorization and searching of Rock-ons.
Implement an Advanced area for generic Docker container orchestration. This should not interfere with the Rock-on UI or cause any confusion for non-advanced users.
We plan to address most if not all of the above limitations in the next phase. The development will be done in a separate branch named after this issue and others, so users can follow the progress. The hosted component bits of the work will be done in rockon-registry repository and will be licensed with GNU AGPL V3.
How is Rockstor itself stored? On a BTRFS pool? Some other FS?
It would be nice if Rockstor was smart enough to present users a choice of where to store the rockons, rather than to be super specific upfront on shares.
Like, say I have Rockstor installed on a small SSD, but everything else is stored on an HDD-based pool. It’d be nice if, upon turning on the feature, my first choice was something like “location”, where I had a popup to choose the SSD, an existing other pool, or a new one.
Rockstor is stored on the root disk, which is a BTRFS pool.
Your point about Storage config for Rock-ons is well put, we are on the same page about streamlining and simplifying the rock-on installation wizard. Thanks!
I currently like how the existing system works as it leads users into separating each of their docker install’s config and data. But yes this is a little over the top for many and a little ping pong on the user interface.
I suggest that we leave the existing rock-ons-root config as it is as that is only a one off anyway. Only obvious addition is an auto option / button, ie:-
Currently we have the explanation header and the selection of the “Root Share”.
In the circumstance where there is only one pool (ie most less advanced installs) offer to create the minimum 5GB Share (it can always be expanded). Named for example “auto_rock_ons_root”.
If more than one user created pool exists then flag the auto option as "only available on single pool configurations, please select an existing Share or create one on your desired pool"
So to summarize the “Configure Rock-on Service” screen would have an “Auto create and configure” button that would create a “auto_rock_ons_root” share and set it in the existing “Root Share” selector once pressed. The button would be greyed out / disabled on multi pool installs and have the above explanation as to why. We can’t know which pool to make a rock-ons-root on so the user will have to do it. But if there was only one user created pool then we can auto make a minimum share for them on the spot. There might also be an opportunity here to sense an existing auto named pool and offer to use it if found. ie the Wizard notices an existing auto_rock_ons_root named share and states its existence and if the user would like to use it, we have to check for it anyway before creating it to making sure we don’t share name clash so we might as well offer up setting a new config to inherit a previous installs auto_rock_ons_root if found (not sure how difficult / feasible this would be though).
As for the individual Rock-on setup wizards we could offer a similar “Auto create and configure” button (big button with that title). Like wise it would in all instances just create a set of minimal shares appropriate for the particular Rock-on. I know this is a little tricky but a basic config size is pretty easy (eg 1GB) and a data size can just start at say 20G (or say 10% of total storage); again all can be resized on the fly anyway and we have nice config areas for all of that.
With this scenario we train the user on the “Auto create and configure” button in the initial Rock-ons configure screen and so when they come across it again they know what to expect; ie it will make and fill out all those storage / config / data share question things that have to be done some how. Given the button suggestion will essentially auto create shares and auto populate the existing config / data questions with those shares it is also clearer to the user what is happening, so they will know where all of these auto_whatever named shares come from when they visit the shares page.
I think this qualifies as fewer inputs as the button is a one click fix for creating and selecting the config & data shares that might be needed. There will however be more actual inputs shown though. Work around if this is not desired is an advanced tick box that shows the existing config / data selectors which might otherwise be hidden.
Of course in all of the above we are assuming a user created pool, if one is not found then just prompt with “no user created pool found / available, please make one here” with a link to jump them to the pools page. Problem is when people want to use the rockstor_rockstor pool (not idea). So we just add “skip to advanced mode” link which activates our tick box and lets users through even if they haven’t created a pool yet.
I was also getting confused about what pool those dedicated shares are ideally a part of (the basic rock-ons share? something else and/or new?), so it’d be nice if the wizard (maybe in conjunction with the global settings for rock-ons?) provided more active help there.
Hello, I move the post below to this thread as it is more appropriate here, sorry if there is some overlap with what has been said before; I did not read it when writing the post below.
I’m a bit short of time, I will edit this post later.
Hello Suman,
I think, we need all four:
tested rockons,
user rock ons,
a limited Docker webinterface DS 5.2 like (this gives a good overview)
and the ability to run Docker from the commandline.
1&2 are obvious and possible as of today. Only a place to exchange is missing.
But I don’t like this. I for myself could life with that, as I can create my own Rock-Ons. But as a pure user, I would be annoyed by the limitation this brings. Why can my friend using a Synology run any Docker, whereas I with rockstor am limited?
This brings me to 3). With this “me too” proposal, one can do a lot already using all rock-ons available in the docker hub. But that is a bit of a ‘pro’ feature and still limited. Compared to a Rock-On two points are inferior:
a) it is not possible to “orchestrate” several docker-containers that shall work together, i.e. a database and the software accessing the database. Rock-Ons, Crane and docker-compose can make sure that the docker containers are started in the right order.
b) for the less advanced user (I hope I phrased this politely) a Rock-On is a lot more convenient than a crane or docker-compose as it guides the user more. It explains, what volume is for what purpose and what port is for which access.
But still, I think Rockstor can learn a bit from the DS5.2 implementation.
Have you thought about a RockOn wizard and/or an importer from crane or docker compose?
I think this could speed-up the availability of more complex Rock-Ons greatly.
Yes separate shares for all rockons seems not intuitive. I normally use one share (docker), and all config files are created under that in separate folder under docker share, like plex, radarr folder etc. An improvement could be that there are one single fixed share, and users can name the subfolders where they would like to put the config files for that particular container.
Documentation could also include alternative strategies so that users can install all the containers they would like, insted of just what is in the rockon list. This could be done by including portainer as a rockon. Then users could easily install alternative containers from linuxserver.io through portainer stack.
I also have OMV6 NAS and they had portainer as an option in something called “OMV-Extras”. Now they have removed this option, and they have gone to their own version of docker-compose plugin. There is no problem get around this, but users have been really frustrated about this, with #1,259 posts about this change before moderator closed the thread.
I think making it easy for users to choose for themselves (non-advanced use rockons) and advanced (portainer with it’s own docker compose) will generate more rockstor users. Advanced user can then install portainer as their only rockon.
