Beiträge von nicjo814

The form in OMV extends this class which could probably be used as a guide on how to add a new button:
https://github.com/openmediava…space/window/Container.js

@subzero79 I think your idea sounds good with adding a new button to the run/modify dialog. I don't know how to do it right away though.

At the same time I think the code for the dialog could be refactored since there is quite some code duplication as it is now...

I have something similar in place an the modify dialog, which will open a popup based on a specific setting (an rpc call and a callback function that will open the popup).

Zitat von no_Legend

Is it possible to allow a port range to the container in the omv docker gui?
It looks like docker can handle it docker run -p 7000-8000:7000-8000

I looked at implementing this kind of functionality quite a while back (I would really love it). However back then there was no way to "identify" port ranges via the API. Instead all ports in a range were listed one by one. I can take another look and see if this has changed lately.

I think I misunderstood the issue Thought it was the wrong images, but you were referring to the width of the buttons right?

I can have a look at my dev system when I get back home from work.

I've looked at the code and it should be the icons located in images/<add|edit|delete> which I believe to be "standard" icons in OMV. I have to admit though that they look weird in your screenshot.

@subzero79 if you have tested the connect /disconnect I would like to first release 3.1.9 and then 3.1.10 immediately after that. I think your additions in 3.1.9 would be very welcome. It will probably even make me upgrade to omv 3.x

Personally I use Docker for more or less everything since I like the way you can run things without affecting the rest of your system and that you can run things which have dependencies that the OS might not support in itself. Then again I build my own images from time to time and feel very comfortable with how docker works I guess the choice of plugins vs docker containers is mostly depending on which method you are most comfortable with.

Zitat von flvinny521

Is there a difference between adding it to the environment variable section vs the extra arguments? I've been using linuxserver containers and just plugging the PUID and PGID as new environment variables.

A really good question. If you add a variable in the GUI as "environment variable" the plugin will add the following to the command being executed "-e <KEY>=<VALUE>", which will tell Docker to add a new environment variable. The extra arguments field is used for Docker parameters that are not supported in the GUI, such as the "--cap-add" parameter. When I designed the plugin I tried to add as few configuration items as possible and still cover as much of "daily use" as possible. Docker comes with a ton of parameters...

EDIT: The PUID and GUID environment variables are things introduced by the linuxserver.io team and is not a part of the Docker framework in itself.

Add the flag in the extra args field just as you wrote it and it should work.

3.1.9 will be released when all the new features introduced have been properly tested. I don't know when this will be though.

Zitat von 1activegeek

@nicjo814 - is it likely this change will affect other things as well? I'm just thinking for example that I run the watchtower container to automatically pull updated images and restart the containers with the new images, then runs a cleanup afterward. I believe this operates by interacting with the docker daemon, and from what I believe I understand, the docker daemon changes from one version to the next here. Just want to be sure to hold off on updating until I've thoroughly tested this. My containers have been so solid for quite some time, I'd really like not to get flack from the household on things not working again! Not to mention I also run security camera software in one container, which I'd like to keep running.

As far as I've understood things the debian package currently used by the plugin (docker-engine) is being replaced by another package (docker-ce). There have been other such changes before with packages called "docker" and "docker.io". I think the Docker team have decided to make a new package again to make a split into one "community edition" (ce) and one "enterprise edition" (ee). Have a look at the change-log available here if you want to know what's new in the latest docker-ce release: https://docs.docker.com/release-notes/docker-ce/

I would guess that changing to the docker-ce package shouldn't be much different from upgrading the previous docker-engine package as is done from time to time.

Zitat von ryecoaaron

That's fine with me. Can you submit a pull request?

Sure, I'll try to do that later tonight. I didn't want to do that without you having a look at it first

Zitat von BarnaM7

Hi,

Is it possible to set fix ip at 3.1.8 to access the service externally ?

thx

Barna

Alles anzeigen

I'm not entirely sure what it is you want to accomplish but I'll give it a shot anyway In 3.1.8 you are limited to setting IP aliases on bridge network for your containers, which might work for your needs or it might not. In 3.1.9 however there will be support for "macvlan" which is like giving a container a "real" static IP.

@ryecoaaron I've done some changes on my fork of omvextras in the 3.x branch located here: https://github.com/nicjo814/openmediavault-omvextrasorg
Have a look and see if this is something you could consider adding to the plugin.

My thoughts is that we could proceed like this:
* Release the docker plugin version 3.1.9 when it's ready and place it in the existing Docker repo of omvextras. This should be the last version of the plugin that gets placed in that repo and this version of the plugin fixes the problem with /etc/systemd/system/docker.service.d/openmediavault.conf. It will also be the last version using the docker-engine package.
* Release docker plugin version 3.1.10 in the new Docker CE repo of omvextras. This version will depend on docker-ce and conflict with docker-engine. The code I added to the omvextras plugin is meant to make it impossible for users to enable the Docker CE repo unless they have version 3,1.9 of the docker plugin installed or if they don't have any version of the plugin installed previously.

I've tested this approach by adding a new bintray repo and temporarily added a 3.1.10 version there which depended on docker-ce. As far as I could tell it worked well and I was able to upgrade from 3.1.9 to 3.1.10 from within the OMV gui.

I'm working on a "proof of concept" that I hope I will be able to complete and test tomorrow.

I have no idea what could be wrong, but can you run systemctl status mysql.service from commandline and post the output here. It might have some information on what's going wrong.

@subzero79 Do you think we should release 3.1.9? I've changed how the docker daemon starts to using dockerd command and updated the controls file to require docker-engine 1.12 (which was when the dockerd command was introduced).

@ryecoaaron I've been thinking a bit concerning this problem with the dependencies. I would like to achieve a solution that don't require the users to enter commands via cli (if possible).

Would it work to add a new repo in omvextras for docker? My idea is that we place the new version of the plugin in there and that there is a control being performed when a user tries to enable that repo. The repo should only be enabled if there is no docker plugin installed or if the version = 3.1.9 which would have fixed the broken file in /etc. I have to admit that I haven't looked at the code for omvextras so I don't know if it's even possible at all

EDIT: To find the installed version of the plugin (numerical value and comparable) something like this could be used:

dpkg-query --showformat='${Version}' --show openmediavault-docker-gui 2>/dev/null | sed -e 's/\.//g'

Sorry I can't help out more. Away on vacation without access to computer right now