Writing Rock-on JSON - how to support multiple path selections in the GUI

Rock-ons
1

Hi there,

Having started to write a Rock-on for Serviio streaming media server as its not in the registry and it could be useful to somebody else, i wonder about a particular implementation detail.

(WIP)
(scusi for the shot-only; iā€™m unsuccessful in correctly quoting the formatted code)

serviio_cropped.png1014Ɨ913 24.5 KB

This Rock-on wonā€™t install for now, so i currently use the plain Docker container created from lsiodevā€™s image, which runs perfectly fine. Cmdline for that:

/usr/bin/docker run --log-driver=syslog -d --restart=unless-stopped --name serviio --net=host -v /etc/localtime:/etc/localtime:ro -v /mnt2/rockons_config:/config -v /mnt2/media_audio:/media/audio -v /mnt2/media_graphics:/media/graphics -v /mnt2/media_video:/media/video -v /mnt2/tmp:/tmp -p 23423:23423/tcp -e PGID=1000 -e PUID=1000 lsiodev/serviio

Now, for the problem: For the /media mountpoint in volumes section, how can one specify a need for multiple selections in the RS UI? With the above, during install i can only select one share. But, i (and maybe others) have separate shares for Audio, Docs, Graphics, Video. All of these should thus be mounted under /media; e.g.

/media/audio
/media/documents
/media/graphics
/media/videos

and so on.
Is there the possibility to get a multi-select dropdown list, or similar, without having to workaround by pre-specifying 4 separate mountpoints like in my case? Scanning f.e. the Plex JSON brought no clues.

If somebody could figure this out; since last night iā€™m working on getting the docker-rdp-calibre to run correctly, and would like to publish this JSON next as calibre ebook content server is up for inclusion too.

2

Ok thanks; understood. Will continue running pure Docker containers then. Makes more sense anyway due to full cmdline & control capabilities. Not being limited by the (current) UI, and not having to create another layer (for no real benefits as it stands).

3

This is interesting observation. Not sure exactly how we should improve this, but Iā€™ve created an issue so we can look back to this post. Thanks @f_l_a

4

From a user perspective, could the ā€œAdd volumeā€ feature be implemented during the initial install of the rock-on? It seems to me that mounting multiple volumes is perfectly implemented already, but only available after the Rock-on install.
In the meantime, if Serviio allows to remap the different media libraries after its install, this could seems like a workaroundā€¦
I found this feature extremely useful to connect what I want between different Rock-ons, so having it available during a Rock-on would seems like a good solution to me (from a user perspective).

5

Thank you, @suman. I thought now and then about an possible approach fo the last couple oā€™weeks.

I can, for now, share basically only my opinion: I would absolutely prefer not having to deal with additional code. That is, avoiding the whole rockon.json concept.

IMHO, it introduces unnecessary additional steps, also maintenance effort; and very small benefits (which basically amount to labeled volumes/port descriptions). And still is not making the whole process super easy for most users who want to introduce other, non-RS-adapted containers into their system.

  1. A user on GitHub mentioned a while ago Synologyā€™s own concept of a Docker GUI, that enables a user to directly install any public Docker image; presumably from the central Docker registry hub.

So they provide a GUI which integrates containers and avoiding special pre-handling of these, allow lifecycle management; without having to care about additional prerequisites.

Not sure however how much effort is required to retrieve available env vars, volumes, exposed ports and other settings an image was build with. Can we somehow extract these from a public Docker buildfile?

EDIT:
No public buildfile access required - simples:

docker inspect imageid can list for object ā€œConfigā€, among other fields:

  • ā€œEnvā€
  • ā€œCmdā€
  • ā€œVolumesā€
  • "ExposedPorts"
    etc.

Also one can re-create the Dockerfile that built a pulled, locally stored image.

Then, a really neat implementation would enable your users to choose how to dynamically map these available options to RS UI elements upon container creation - f.e. mapping multiple shares to specific container volumes. And provide port mapping overrides, etc. etc.
Thus, completely avoiding the current, rather static approach which is mandated by these Rock-on JSON-based meta-file descriptions.

  1. I would also prefer being able to edit/specify Docker cmdlines for each container, f.e. to choose restart options.

  2. For now, iā€™ve set up my server with ui-for-docker instead of RSā€™ native UI. Itā€™s quite nice, a container as well; but either misses the create container & cmdline features, or i havenā€™t found them yet. 20160625: Both are there; excellent. It is a good (also reference) UI.

What do you think about my ideas? I envision another differentiation feature for RS here.

(Btw: thanks for releasing 3.8.14 this week. And therefore i purchased the 5y plan to support RS, as indicated before.)

PS: what is the best option to submit issue reports/CRs for users without a GitHub account and without Incident plan? Or should i better create a GH account?
I guess you guys do not have just enough time to comb thru the forums regularly. Time is often indeed spend better.

1 Like
6

You bring up excellent points. These are expected challenges when you try to integrate two open source projects 1) without reinventing the wheel and 2) add differentiation.

Our original vision was to provide a simple UI over docker and let users add their own registries besides the hub. But for the first iteration, I wanted to emphasize the idea of Docker based apps using BTRFS/Rockstor storage platform. So our focus has been just that. I have to say that my experience with performance and stability has not been that great but consistently improved since Rock-ons were first launched. This is both due to BTRFS and Docker as theyā€™ve been evolving quite rapidly and we are pulling in changes as rapidly as we can.

I do think we need to think of next iteration of Rock-ons framework and youā€™ve echoed my intuition in your well articulated post. We are sure to factor in your points heavily as we go forward. so, thanks for that.

Most issue reports are best submitted on our github issue tracker. You can also start a forum topic like this one for a major feature that can benefit from a discussion by everyone here.

Thank you for subscribing to stable updates and supporting us. Really appreciate it!

2 Likes
7

I appreciate the insight given. Typically, it is a long road; from ideas to IOC, and then forward to something more substantially, all the next months striving towards feature-completeness. Usually accompanied by certain changes to the initial vision.

Personally, i learned much about how Docker operates; will definitely come in handy on the job as well. :wink:

Thanks @suman for seeing my follow-up as well articulated. Usually written & spoken English (iā€™m no native but close to 80, 90% of my daily business involves it) is the same to me. Re-read my post today as being somewhat clumsy, though; so had to further edit. Tiring week.

Ok will see how to further any future issues. Currently iā€™m quite satisfied, despite experiencing a somewhat rough start with RSā€¦ and then for some time. So my only pet peeve today would be missing support for VLAN connections.