Unknown internal error doing a POST to /api/rockons/update (old fix gone)

[Flox]

Hi @jimla1965 ,

Pardon the delayed feedback on the following; time has been very very rare for me lately. I wanted to chime in on your input and ideas below:

@jimla1965

A better customer experience would be installing the Rock-ons totally at install time using the boot drive by default, ready to use. Then at the point of installing first container or running update, ask if they would like to improve performance by suggesting a default share name and best drive both which user can change. Don’t require the customer to leave Rock-ons to create the share, just do it for them.

I see 2 points here:

• point 1: improving the Rock-Ons update mechanism by, in part, making use of a local resource, possibly available at Rockstor install time.
• point 2: ease the creation of shares required by Rock-ons during their install by having Rockstor take care of some of that “requirements” work.

Point 1: improve the Rock-Ons update mechanism

Yes. Absolutely agree. Our current mechanism has been serving users relatively well for a long time but as the size of the Rock-Ons registry grew rather large, this mechanism started showing some limitation. Improving how we update the list of available Rock-Ons has been and still is a rather high priority item on the list. We are fortunate enough to have a few members of this community who detailed their ideas on how to do just that and implement a few improvements, so I think we have a good ground on which to build now. I unfortunately cannot seem to find them all at the moment, but a few examples can be found below:

More native docker approach for Rockons (docker)

In a previous post I briefly mentioned using a more native docker approach for Rockons. In this thread I would like to go deeper into my train of thoughts and discuss any potential issues, shortcomings, oversights, etc. with the proposed approach. Let’s start with what I gathered so far about the Rockons (please correct me if I’m wrong): A Rockon configuration is a JSON file with the needed parameters to start up a docker container for that application including data needed by the Rockon wiza…

Request: better rockon update protocol

Currently: root.json contains a list of: 'human project name' : 'project.json' for each rockon root.json and all project.json files are pulled every update. Failure to pull them all seems to result in an aborted update with no results. This data seems to be held in memory and not written to the rockons share (or maybe it isnt until its fully downloaded so any timeout aborts the whole process) rockon update pulls a meta list from /rockons/root.json (as http and gets redirected to https, …

Although our top priority is to focus on our now-reducing technical debt, reworking the Rock-Ons update mechanism might be initiated at the same time. This would be a rather large change, however, so this will most likely need to occur in steps and I do think we can, for instance, start by reducing our interaction with the remote Rock-On registry and make use instead of local resources. This should greatly improve situations such as yours in which this remote fetching mechanism appears consistently problematic. I can see a path to implement this without needing to alter our current database structure, and this would represent a big advantage in being able to take this on while we are still making big changes to our Django and Python updates.

Point 2: automate share creation for Rock-Ons

Here again: yes… completely agree.
This too is a point on our to-do list, and part of a wider set of improvements to shares/paths management during Rock-Ons install. See the following GitHub issues, for instance:

[Rock-Ons] Allow mapping/mounting of individual folders instead of only shares

Allow storage definition within Rockon install UI

Hope this helps, and thanks again for sharing your feedback, ideas, and your willingness to help test their implementation!