[OUTDATED] Extended Docker configuration page


Recommended Posts

You're right. That's a shadowbox bug. Do you see anything when you hit Info in the webGUI?

 

Yes, it shows System Info correctly. However... I had popped up the window, then switched to another tab to type this, and went back, and the shadowbox is empty, and frozen on screen again. From UnMENU if I re-select UnRAID Main everything behaves properly.

 

Ok, I tracked this down to the prompt javascript plugin i'm using.

 

I'll test it further. In the mean time, please use other browser.

 

I've added a note to the beta6 thread of this issue as well. If you resolve, you may want to drop Jonp a note or respond to my post in the Announcements forum.

 

Thanks for looking into this.

Link to comment
  • Replies 635
  • Created
  • Last Reply

Top Posters In This Topic

You're right. That's a shadowbox bug. Do you see anything when you hit Info in the webGUI?

 

Yes, it shows System Info correctly. However... I had popped up the window, then switched to another tab to type this, and went back, and the shadowbox is empty, and frozen on screen again. From UnMENU if I re-select UnRAID Main everything behaves properly.

 

Ok, I tracked this down to the prompt javascript plugin i'm using.

 

I'll test it further. In the mean time, please use other browser.

 

I've added a note to the beta6 thread of this issue as well. If you resolve, you may want to drop Jonp a note or respond to my post in the Announcements forum.

 

Thanks for looking into this.

I think I've fixed the prompt command. Update and try now.

Link to comment

It it also possible to show commit/revision changes from the beginning of your Docker Manager - I was thinking that the version number on the Extensions/plugin page could be a hyperlink that when clicked on would opened a new window with a commit history for the revisions

Link to comment

It it also possible to show commit/revision changes from the beginning of your Docker Manager - I was thinking that the version number on the Extensions/plugin page could be a hyperlink that when clicked on would opened a new window with a commit history for the revisions

 

Or just take a look into the github repo, but that should be useless, since I don't bother to name all fixes the right way....  ::)

 

When we go stable, I'll begin to track the changes, ok?

 

This time, I have changed the prompt javascript plugin, since the old one, Impromptu, has some inconsistencies with MSIE, that shitty browser (my respects to those who use it!)...

 

Now I have updated the jQuery UI, since the version used by LT lacks dialog boxes (this is serious, Tom).

 

I have no skills in CSS styling, so if anyone want to make it prettier, be my guest!

Link to comment

It it also possible to show commit/revision changes from the beginning of your Docker Manager - I was thinking that the version number on the Extensions/plugin page could be a hyperlink that when clicked on would opened a new window with a commit history for the revisions

 

Or just take a look into the github repo, but that should be useless, since I don't bother to name all fixes the right way....  ::)

 

When we go stable, I'll begin to track the changes, ok?

 

This time, I have changed the prompt javascript plugin, since the old one, Impromptu, has some inconsistencies with MSIE, that shitty browser (my respects to those who use it!)...

 

Now I have updated the jQuery UI, since the version used by LT lacks dialog boxes (this is serious, Tom).

 

I have no skills in CSS styling, so if anyone want to make it prettier, be my guest!

 

ok sounds good - was just providing feedback to assist with everyone's user experience

Link to comment

I have no skills in CSS styling, so if anyone want to make it prettier, be my guest!

 

Give me form over function any day.

 

LT wouldn't be wasting their time to move to a bootstrap type framework then everyone can make it as pretty as they want.  Though bootstrap is suffering from overuse.  Too many sb sites out there now.

 

Do you use a an underlying CSS or just hang off the LT base ?

Link to comment

Is there any way to make the installer verbose or have a progress bar of some kind so you know where it is in the install process and how much longer remains for it to finish? Please wait with three animated dots doesn't tell you much (is it still working, did it hang? ...)

 

Thank you!

Link to comment

Is there any way to make the installer verbose or have a progress bar of some kind so you know where it is in the install process and how much longer remains for it to finish? Please wait with three animated dots doesn't tell you much (is it still working, did it hang? ...)

 

Thank you!

 

There are logs that are too big to be handled by the web browsers, so proc_open() is not the answer, so I used exec(), that only export the output after it finishes, so it's already verbose, but only after the command has finished. I put that animation to let users know the process is still running in the background. There is no way to put a progress bar because there no way to predict the amount of data that need to be downloaded.

Link to comment

I have no skills in CSS styling, so if anyone want to make it prettier, be my guest!

 

Give me form over function any day.

 

LT wouldn't be wasting their time to move to a bootstrap type framework then everyone can make it as pretty as they want.  Though bootstrap is suffering from overuse.  Too many sb sites out there now.

 

Do you use a an underlying CSS or just hang off the LT base ?

 

I've sticked to LT css the most to maintain the webGUI identity, just a few fields needed some tweaking, mostly width related.

Link to comment

Nice work.

 

Couple of thoughts:

 

Is it viable to present the base OS of each container in the GUI so that users can start to see the variations?

 

The templates are especially nice. Could we set a global base path and then create the "Host path:" automatically. i.e. if i set base path as /mnt/user/apps/docker/ then for MariaDB we could have "/db:rw <> /mnt/user/apps/docker/needo/mariadb/default/db" User could change this but at least by default it would be created and not potentially clsh with other versions.

 

Can go into these more if they are of interest.

 

Kudos

Link to comment

Nice work.

 

Couple of thoughts:

 

Is it viable to present the base OS of each container in the GUI so that users can start to see the variations?

 

The templates are especially nice. Could we set a global base path and then create the "Host path:" automatically. i.e. if i set base path as /mnt/user/apps/docker/ then for MariaDB we could have "/db:rw <> /mnt/user/apps/docker/needo/mariadb/default/db" User could change this but at least by default it would be created and not potentially clsh with other versions.

 

Can go into these more if they are of interest.

 

Kudos

 

1) Base OS: it's viable, but I don't see any benefits of display it. Most users will deploy the templates, so this information is useless. I can add this info in the templates description, tho. All included templates are using Phusion image currently;

 

2) This can be done, but will need that every container stores it's data to /config, but many doesn't, eg ownCloud and MariaDB. The file browser is easy enough to use, and users should rely on them to set their paths.

Link to comment

1. Thats fine at least its starting to make user more aware that underneath it all there are OS dependencys.

 

2. I am not sure I used a good example. The idea is to inspire users to use a an organised path for configuration files. We are already seeing users getting confused with this and using random google answers to the wrong questions e.g. /opt. Also sets a safe standard so that different docks of the same app dont clash. I just think that allowing the user to set a base path once and then suggesting paths in the tempates based on the base is more elegant. It also means that if a user can select a template and then press add and by default it will work.

Link to comment

Is there any way to make the installer verbose or have a progress bar of some kind so you know where it is in the install process and how much longer remains for it to finish? Please wait with three animated dots doesn't tell you much (is it still working, did it hang? ...)

 

Thank you!

 

There are logs that are too big to be handled by the web browsers, so proc_open() is not the answer, so I used exec(), that only export the output after it finishes, so it's already verbose, but only after the command has finished. I put that animation to let users know the process is still running in the background. There is no way to put a progress bar because there no way to predict the amount of data that need to be downloaded.

 

Gotcha. When you initiate docker run from the command line and it needs to download packages, it downloads each in turn and you can watch the amount downloaded versus what remains and sort of guesstimate how long it's going to take. That's what I meant by verbose. It seems to be working great otherwise.

Link to comment

1. Thats fine at least its starting to make user more aware that underneath it all there are OS dependencys.

 

2. I am not sure I used a good example. The idea is to inspire users to use a an organised path for configuration files. We are already seeing users getting confused with this and using random google answers to the wrong questions e.g. /opt. Also sets a safe standard so that different docks of the same app dont clash. I just think that allowing the user to set a base path once and then suggesting paths in the tempates based on the base is more elegant. It also means that if a user can select a template and then press add and by default it will work.

 

1) I could suggest that in the templates, e.g. /mnt/cache/appdata/{name of the container}, but it should be user decision to stick with these.

 

2)  Containers of the same app should be handled as different containers, with different paths/ports/name. I don't see any problems here. The average user will run only one instance of each app. Those who wishes to run more than one instance should be more tech savvy to know how to configure them differently.

Link to comment

Is there any way to make the installer verbose or have a progress bar of some kind so you know where it is in the install process and how much longer remains for it to finish? Please wait with three animated dots doesn't tell you much (is it still working, did it hang? ...)

 

Thank you!

 

There are logs that are too big to be handled by the web browsers, so proc_open() is not the answer, so I used exec(), that only export the output after it finishes, so it's already verbose, but only after the command has finished. I put that animation to let users know the process is still running in the background. There is no way to put a progress bar because there no way to predict the amount of data that need to be downloaded.

 

Gotcha. When you initiate docker run from the command line and it needs to download packages, it downloads each in turn and you can watch the amount downloaded versus what remains and sort of guesstimate how long it's going to take. That's what I meant by verbose. It seems to be working great otherwise.

I got you! That behavior would require the use of proc_open(); even then I couldn't get those messages because the docker program output them in the stdin pipe, and not in the stdout. I've already tried that!  ::)

 

 

Link to comment

FOR EVERYONE:

 

I'm considering output the paths used in the containers list, but since it became so bloated with data, I must iron out some info. I'm considering the COMMAND column, since that information is a bit of useless. What do you think?

 

Link to comment

FOR EVERYONE:

 

I'm considering output the paths used in the containers list, but since it became so bloated with data, I must iron out some info. I'm considering the COMMAND column, since that information is a bit of useless. What do you think?

 

I think that's a good idea!

Link to comment

1. Thats fine at least its starting to make user more aware that underneath it all there are OS dependencys.

 

2. I am not sure I used a good example. The idea is to inspire users to use a an organised path for configuration files. We are already seeing users getting confused with this and using random google answers to the wrong questions e.g. /opt. Also sets a safe standard so that different docks of the same app dont clash. I just think that allowing the user to set a base path once and then suggesting paths in the tempates based on the base is more elegant. It also means that if a user can select a template and then press add and by default it will work.

 

1) I could suggest that in the templates, e.g. /mnt/cache/appdata/{name of the container}, but it should be user decision to stick with these.

 

2)  Containers of the same app should be handled as different containers, with different paths/ports/name. I don't see any problems here. The average user will run only one instance of each app. Those who wishes to run more than one instance should be more tech savvy to know how to configure them differently.

 

Yes sorry the idea is not to force the user to use something .... just to suggest something sane and predictable and if they dont care then they end up with something nice by default. If they do care then they simply change it.

 

I would suggest that "/mnt/cache/appdata/{name of the container}/folder" be

 

"/mnt/cache/appdata/" - user configures once and it becomes common to all container settings

{name of the container} - follow the docker repo name but also add the last silent tag i.e. /needo/mariadb/ becomes /needo/mariadb/default/ so that we can handle tags such as /needo/mariadb:latest

/folder - just using the name from volume by default

 

Something also to consider is to not use "/mnt/cache/appdata/" but "/mnt/user/appdata/". unRAID will make less mistakes this way i.e. you dont get slow mv performance when it doesnt realise the source and destination is on the same physical drive

 

 

Link to comment

 

I would suggest that "/mnt/cache/appdata/{name of the container}/folder" be

 

"/mnt/cache/appdata/" - user configures once and it becomes common to all container settings

{name of the container} - follow the docker repo name but also add the last silent tag i.e. /needo/mariadb/ becomes /needo/mariadb/default/ so that we can handle tags such as /needo/mariadb:latest

/folder - just using the name from volume by default

 

Something also to consider is to not use "/mnt/cache/appdata/" but "/mnt/user/appdata/". unRAID will make less mistakes this way i.e. you dont get slow mv performance when it doesnt realise the source and destination is on the same physical drive

 

1) Don't you think that path will become extremely long with apparently no reason?

 

2) Yes, maybe "/mnt/user/appdata" a good idea. Let's open it for debate!

Link to comment

FOR EVERYONE:

 

I'm considering output the paths used in the containers list, but since it became so bloated with data, I must iron out some info. I'm considering the COMMAND column, since that information is a bit of useless. What do you think?

 

I think that's a good idea!

 

Ok, I've updated this, but left the COMMAND column in place.

 

Let me know what do you think about it.

Link to comment

any way of seeing the progress of the docker build/pull ?

trying to install crashplan with this new gui.... but i am waiting and waiting and drink a beer and waiting and waiting ........... and drinking

 

30 minutes so far nothing moves ...

/var/log/docker.log shows me this

2014/07/08 21:17:05 POST /v1.12/containers/create?name=CrashPlan

[71c3592f] +job create(CrashPlan)

No such image: gfjardim/crashplan (tag: latest)

[71c3592f] -job create(CrashPlan) = ERR (1)

[error] server.go:1025 Error: No such image: gfjardim/crashplan (tag: latest)

[error] server.go:90 HTTP Error: statusCode=404 No such image: gfjardim/crashplan (tag: latest)

2014/07/08 21:17:05 POST /images/create?fromImage=gfjardim%2Fcrashplan&tag=latest

[71c3592f] +job pull(gfjardim/crashplan, latest)

 

seems he is pulling....

 

also in my other server i can't seem to set needo/plex to autostart

i tick it ... the page refreshes and it is unticked again ...

 

Link to comment

any way of seeing the progress of the docker build/pull ?

trying to install crashplan with this new gui.... but i am waiting and waiting and drink a beer and waiting and waiting ........... and drinking

 

30 minutes so far nothing moves ...

/var/log/docker.log shows me this

2014/07/08 21:17:05 POST /v1.12/containers/create?name=CrashPlan

[71c3592f] +job create(CrashPlan)

No such image: gfjardim/crashplan (tag: latest)

[71c3592f] -job create(CrashPlan) = ERR (1)

[error] server.go:1025 Error: No such image: gfjardim/crashplan (tag: latest)

[error] server.go:90 HTTP Error: statusCode=404 No such image: gfjardim/crashplan (tag: latest)

2014/07/08 21:17:05 POST /images/create?fromImage=gfjardim%2Fcrashplan&tag=latest

[71c3592f] +job pull(gfjardim/crashplan, latest)

 

seems he is pulling....

 

also in my other server i can't seem to set needo/plex to autostart

i tick it ... the page refreshes and it is unticked again ...

 

Try in the command line : docker pull gfjardim/crashplan . See if it goes on error too.

Link to comment

Would be nice if the plugin gave a more detailed description of the template container paths and template environment variables as a guide to mapping / setting them effectively. I had a few missteps that required research in the forums to understand their use. There is hover text but it is generic. Maybe container creators could draft this usage information?

 

Thoughts?

Link to comment

I'm considering output the paths used in the containers list, but since it became so bloated with data, I must iron out some info. I'm considering the COMMAND column, since that information is a bit of useless. What do you think?

 

I'm not sure what you mean by 'output the paths used', but the COMMAND column is somewhat useless, so it a good candidate for removal/replacement.  Also, the autostart column is rather wide, for just the checkbox.  I don't know how to make it more narrow, while still including a label/header, but it's something to consider.

 

Something also to consider is to not use "/mnt/cache/appdata/" but "/mnt/user/appdata/". unRAID will make less mistakes this way i.e. you dont get slow mv performance when it doesnt realise the source and destination is on the same physical drive

 

2) Yes, maybe "/mnt/user/appdata" a good idea. Let's open it for debate!

 

If someone sets the /mnt/cache/appdata/ folder as cache only (which they need to do to avoid their settings getting moved), then the mover should not bother with it, so I'm not sure what we're saving, or improving with this.  Not to say it's a bad idea, just saying.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.