Thanks for your help. I see and understand the mistakes. I am struggling though to re-load the json. The Port-Mappings are still wrong by default.
To make sure, that Rockstor is re-loading the json, I have re-named the json and the name of the Rock-On in the .json, but Rockstor still presents me the old one.
(procedure:
uninstall old
hit reload
install
–> still old port mappings
uninstall again
rename .json
change name:
{
“SqueezeBoxServerNEW”: {
“containers”: {
hit reload
–> Still SqueezeBoxServer is presented as available rock-on. Still with the old port-mappings.
The Reason is this:
Traceback (most recent call last):
File "/opt/rockstor/src/rockstor/storageadmin/views/rockon.py", line 101, in post
self._create_update_meta(r, rockons[r])
File "/opt/rockstor/eggs/Django-1.6.11-py2.7.egg/django/db/transaction.py", line 371, in inner
return func(*args, **kwargs)
File "/opt/rockstor/src/rockstor/storageadmin/views/rockon.py", line 149, in _create_update_meta
handle_exception(Exception(e_msg), self.request)
File "/opt/rockstor/src/rockstor/storageadmin/util.py", line 43, in handle_exception
raise RockStorAPIException(detail=e_msg)
RockStorAPIException: Container(squeezebox) belongs to another Rock-On(SqueezeBoxServer). Update rolled back.
I think, this could be improved (at least some message in the UI would be good).
But still… I cannot get the port-mappings right. Supervisord and the Webserver are always swapped.
Even deleting the json from the folder “rockon-metastore” does not remove it from the Web-Interface.
Is there any way, I can force to remove the remains of the old RockOn?
@henfri [quote=“henfri, post:21, topic:298”]
Is there any way, I can force to remove the remains of the old RockOn?
[/quote]
You could try the procedure detailed by @suman in another Rock-ons related thread post by:- [quote=“suman, post:15, topic:794”]
… just starting over with a new [Rock-ons] root share.
[/quote]
Details of the procedure are in the linked post.
Love the whole “NAS + docker” idea behind Rockstor myself as well. All I really want is what Rockstor currently offers (and isn’t fuzzy about, the pool / shares / protocol stuff is great) and support for isolated services. And then to not just have a CLI somewhere, but a web-ui that helps the less savvy co-users operate the system.
Love the idea of those three steps, but wonder if there isn’t a good idea to just let people upload their own dockerfiles?
Grab tested and documented Rock-ons, or build your own stuff, and run it with no warrantee what-so-ever.
Good idea to label the “official” and “community” containers as such.
Me personally? I would just like to see a “nginx” / “apache” and “NodeJS” Rock-on. For when you need to host that simple site or webservice. Or perhaps to use as an interface for Rockstor in a domotica setting with a SoC somewhere in the network.
@Philip:
Thanks for your suggestion. Nothing easier than that; It’s a VM only and this RockOn is the only one --> Nothing to loose.
BUT: Because this is not a production System, I think we could use the opportunity, to make this more stable and to FIX the Bug.
I in fact see two problems here:
a) Once 3rd party rock-on is installed, it cannot be changed anymore (I also tried to increment the “version” parameter in the json, which sounds quite useful for the purpose; no change)
b) If a Container(squeezebox) belongs to another Rock-On(SqueezeBoxServer), i.e. if someone else also provides a Rock-On using the same container, the User just does not get to see this second RockOn. Not even an Error-Message.
Don’t get me wrong, I can solve my problem by starting over. (I’d be done by now but I’d like to contribute by helping to improve the stability.
Love your attitude @henfri. I am glad we are collaborating on this experiment. This is indeed the right opportunity to make things more robust. I’ve created an issue to do just that and your Rock-on is the right candidate to trigger this bug. Stay tuned, here’s the issue:
@phillxnet, thanks as always for being our helper-in-chief! But I think we have a budding core contributor here
We are on that path @JEV. I could easily make the Rock-On framework into a simple GUI layer of docker and leave users to deal with putting it all together. But it would (1) turn Rockstor into a kitchen sink like some other projects out there and (2) it would require users to be sufficiently proficient in docker, at which point, they can just easily manage it all from the CLI using docker and docker-compose. So I am walking a fine line here between not restricting the users in any way by giving them the ability to add their apps and building a decent UX.
I already (unofficially) use the apache Rock-on, it’s coming… My current focus is on making the framework more robust so other savvy badasses like @henfri are empowered to pitch in.
The plex Rock-On provides a link to the Plex-Webui in the Rockstor-Web-Ui. How can I do this for 3rd party Rock-Ons?
Apart from that, I see a problem with the Configuration-Subvolumes:
Curently, I am using the same Subvolume to every Rock-On:
/mnt2/RockOns_config
This is dangerous, as there can be file collisions between different Rock-Ons
Better would be providing -or automatically creating- a Folder or a sub-Subvolume (not sure whether this is possible) within this Subvolume.
E.g. one would specify the Share /mnt2/RockOns_config in the configuration of the Rock-On, but this would automatically create a folder/subvolume
/mnt2/RockOns_config/plex/
The alternative is of course to create subvolume per Rock-On by hand:
/mnt2/RockOns_config_plex
/mnt2/RockOns_config_logitechmediaserver
/mnt2/RockOns_config_btsync
/mnt2/RockOns_config_syncting
But this would be very unstructured and full after a while…
On top, I have another question:
Is there a way, to run a Rock-On with the parameter --privileged and to specify/mounts volumes that are not a subvolume and not user-definable?
I am trying to create a docker-ui rock-on but it requires this:
docker run -d -p 10.20.30.1:80:9000 --privileged -v /var/run/docker.sock:/var/run/docker.sock dockerui/dockerui
Apart from that, I see a problem with the Configuration-Subvolumes:
Curently, I am using the same Subvolume to every Rock-On:
/mnt2/RockOns_config
This is dangerous, as there can be file collisions between different Rock-Ons
Better would be providing -or automatically creating- a Folder or a sub-Subvolume (not sure whether this is possible) within this Subvolume.
E.g. one would specify the Share /mnt2/RockOns_config in the configuration of the Rock-On, but this would automatically create a folder/subvolume
/mnt2/RockOns_config/plex/
The alternative is of course to create subvolume per Rock-On by hand:
/mnt2/RockOns_config_plex
/mnt2/RockOns_config_logitechmediaserver
/mnt2/RockOns_config_btsync
/mnt2/RockOns_config_syncting
But this would be very unstructured and full after a while…
but I’d like to contribute by helping to improve the stability.