[Suggestion]: Better/clearer wizard and/or folder structure

Rock-ons
1

I am currently testing out Rockstor and got stuck trying to install RockOns. I browsed the forum and stumbled upon this post, which was the key to getting the installs to work:
https://forum.rockstor.com/t/fails-to-install-rockons/2703

I am a bit surprised that 5 years later this issue, which can be addressed quite easily, has received no updates. Therefore I would like to make some suggestions. I will use the Couchpotato plugin as reference. It requires 3 folders: Config, downloads and movies.

  1. Quick win: Prevent the user from selecting the same folder multiple times. This will prevent the user from selecting the same folder, which is not allowed by docker bind in the background.
  2. Update the way configs are saved: Since only shares can be selected, and shares have a flat structure (you cannot make or select subfolders) you need to create a separate share for every plugin that requires a config file. For config files, it might be interesting to have a config root share and have the wizard create a subfolder in that share with the name of the plugin in which the config can be saved. This will prevent the creation of a lot of shares for storing separate configs.

I hope at least the quick-win can be implemented, because I spent way too much time figuring this out for something that could have been prevented so easily.

1 Like
2

Hi @stitch10925, and welcome to the community!
Happy New Year as well (although maybe a bit in advance depending on where you are).

Thanks for your feedback and taking the time to share your recommendations and ideas; that is always very appreciated and motivating for us! Thanks also for sharing your resolution on the other thread.

I personally completely agree with you on the points you’ve made. As you noticed, this is something that had been raised quite some time ago indeed, and I’m personally partly to blame on this one as I originally intended to tackle this and was hoping to have that done much sooner.

Thank you for detailing your ideas on how to resolve this; they actually do fit perfectly with all the discussions that happened around this. See for instance, the various GitHub issues we have to track this issue and the proposed ways to resolve it:
https://github.com/rockstor/rockstor-core/issues/2399#issue-1385168446
https://github.com/rockstor/rockstor-core/issues/2258#issue-791351389
https://github.com/rockstor/rockstor-core/issues/2064

As you can see in these discussions, we do plan on addressing this in a variety of ways:

  • improved form validation to prevent the user from selecting the same share multiple times as this is currently not supported
  • allow for increased flexibility in the selection of a share that would contain various sub-directories for each Rock-on config (and more)
  • automatic creation of required shared during a Rock-on install wizard

What do you think about this approach? From your very helpful feedback, I think it seems to fit very well but thanks for letting us know more; we’re always very hungry for this kind of constructive feedback.

As you can see in these issues and the links therein, this is high on our list of features update and fixes. In case you would be curious and willing to have a look at that yourself, please find below our docs on how to do just that. Of course, we’re also always here to provide more info as needed and requested here.
https://rockstor.com/docs/contribute/contribute.html

I wanted to take the opportunity to provide some background here… my apologies in advance for veering a bit off-topic. @phillxnet (Rockstor’s maintainer) will be able to describe that better as needed, but in the past few years, we’ve had to spend most of our development effort on migrating our OS base (from CentOS to openSUSE) following the former’s deprecation of Btrfs support. This was a massive undertaking but has brought immeasurable benefits such as the first-class Btrfs support in openSUSE. Inherently, we’ve also had to make a lot of changes and improvements behind the scene, with a completely new ISO creation system (see GitHub - rockstor/rockstor-installer: The kiwi-ng configuration used to create Rockstor 4 'Built on openSUSE' installers.) to allow us to easily expand the number of systems for which we can build ISOs/images (we now support Raspberry Pi 4, for instance) and allow folks to create their own ISO as needed. @phillxnet also focused on building a very robust and flexible back-end for better testing and deployment of new releases. We thus have had to spend a lot of effort on strengthening/building a robust behind the scene base so that we could release much needed big changes more safely and thus more quickly. Thanks to this new base, we are now tackling our technical debt and we’ve already made substantial strides recently with a big update to our Django base and dependencies in the testing channel:
V4.5+ Testing Channel Changelog

@phillxnet has also been very very hard at work on modernizing our build process as we’ve been unfortunately hit by an unexpected emergency there. See the following for more details on the recent changes in since our last Testing channel release, for instance:

Again, thank you so much for your constructive feedback, and please let us know if you still have more questions. I hope I could at least provide some answers to your questions.

2 Likes
3

Hello @Flox and @phillxnet ,

First of all I would like to wish you a very happy new year! Thank you for taking the time to elaborately answer my post and to provide so much detail. My apologies for not searching the forum before making my post, which caused me to miss the fact that there were already 3 related posts that basically describe everything I said.

From other posts I already picked up on the fact that there was an OS-shift from CentOS to OpenSUSE, I can imagine that this took a lot of effort from everyone involved and caused some of the smaller issues to move to the background. I can only applaud all the work that has been put into the OS migration and the general work around Rockstor. Still, Rockons are a very important feature of your product and the fact that it’s based on Docker makes it even more appealing. To not have implemented at least form validation to tell the users what they did wrong, and having the Rockon fail silently, feels like a missed opportunity that might have caused some users to give up on the software, which is a real shame, because Rockstor, from what I have seen so far, seems like a really nice piece of software.

I’m not sure if this is the right channel to talk about the Rockon implementation, if not, we can take this offline if you want. I had a quick skim over the Rockon Framework implementation. What really surprised me is how much Rockon data is stored in the database instead of making use of the information docker provides out of the box. I realize I do not know the internals of Rockons nor Rockstor at all, nor the technical reasons for the design decision (maybe performance or other reasons), so what I am saying could be totally misplaced, if so I apologize. However, I believe that a more native docker approach might be more beneficial and less development work in the long-run. If you would like more information on my thoughts on this, let me know, I will gladly provide my insight.

Again, thank you to everyone involved with Rockstor. You are doing an amazing job with this simple to use, non-bloated, yet very functional piece of software. I am really curious te see how it will evolve in the future!

Sincerly

3 Likes
4

Hi @stitch10925,

I agree… I think my personal view on that matter was that I would have been able to attack that issue at the time and thus would have been able to fix it at the source, which would have been more important than trying to circumvent one of the ways it is showing to the user (which is what adding the form validation first at the time would have represented in my opinion). The reality clearly showed that was the wrong approach so I do think we should implement that form validation first and then attack the source once the developer time is ready for it. @phillxnet, unless you see a major downside to it, I think I’ll try to break down the current issue into separate ones so that we can address those that don’t require backend modifications; the form validation should hopefully be doable only on the JS side of things.

I appreciate you asking, thank you for your diligence… This forum is the recommended place to do that. We usually prefer to use the forum for all communications (or even its PM feature in case a user needs to share something that includes private/sensitive information) so that we have a public and searchable record for all troubles and resolutions.
In case of bugs/issues, we discuss them here first so that we can try to identify the source of the problem and then once we have a reproducer, a Github issue should be created on the corresponding Github repository so that we can track it and resolve it.
With regards to discussion and feedback such as you want to initiate: this forum is actually the perfect place to do that! We’re always eager to get a constructive feedback and conversation so thank you in advance for doing so! Feel free to create a separate thread as it seems you would like to talk about a wider topic than this current one. The more focus the thread the better as it makes it easier to find relevant information through search in the future.

You did mention the Rock-Ons framework so I will link to the relevant wikified post I wrote a little while ago. You already found and read it but I’m posting it here anyway for other users who may not have:

I’m really interested by that so that’s exciting! We have had some feedback already that we would like to implement and I myself have some thoughts on the matter as well but I’ll try not to mention that first so that you can present your ideas in an “unbiased” manner.

Looking forward to reading you.

2 Likes
5

@Flox, @phillxnet,

I created a new thread regarding a more native docker approach here:

2 Likes
6

I have now pushed a commit to my fork to add form validation to prevent the user from selecting the same share to be bound to multiple volumes as this isn’t supported yet.

@stitch10925, thanks for letting me know what you think of it. This is only a short-term solution until we do support a better mechanism as was discussed earlier in this thread, but at least it will prevent the user to unknowingly select a broken configuration for now.

3 Likes
7

That will help tremendously, I’m sure. Obviously it’s impossible to overhaul the whole Rockon system over this. So indeed, this is a great quick-win.

3 Likes
8

Thanks!
I just realized I forgot to link to the comment that describes it so I edited my post above accordingly.

9

The form validation mentioned above is now released in Rockstor-4.5.6:

Thanks to @stitch10925 for this!

4 Likes