@nicjo814 and @subzero79 when do you want to change the dependency from docker-engine to docker-ce? There is a pull request in the omv-extras plugin queue to change the repo to the new url which uses docker-ce package (and requires docker-engine to be removed).
Docker GUI plugin now stable
-
- OMV 2.x
- nicjo814
-
-
Going to work on the weekend on the dc button. I haven't read about docker-ce yet.
-
@subzero79, @ryecoaaron I tested to change to docker-ce and encountered some issues. First if the dependencies change in the debian/control file the package will be held when doing and apt-get update/upgrade (at least via cli which was what I tested). The package had to be installed via apt-get install <package>. The changes I did was to Depend on docker-ce and to Conflict with docker-engine. Except from the issue mentioned above the principle seemed to work.
However I ran into another issue which might be a bit trickier to fix. We have included a file /etc/systemd/system/docker.service.d/openmediavault.conf which make the docker daemon start via the command "docker daemon". This command is deprecated in docker-ce and thus the installation fails as soon as docker-ce is installed and that package tries to restart the docker daemon. I haven't yet come up with a clean solution on how to modify this file before docker-ce gets installed. Do you have any ideas?
-
Do you have any ideas?
Unfortunately, if docker-ce is a dependency of the plugin, it will always be installed before the plugin. The only idea (other than having users do something on the command line) I have is to change the current plugin to remove that file on uninstallation (remove not purge). Then we rename the current plugin adding a conflict with the old plugin name. Ugly I know.
-
@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'
-
@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).
-
I have to admit that I haven't tested thoroughly the connect/Dc button. I don't know if omvextras testing repo would allow to push the plugin in that channel to get some feedback.
-
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
It would be possible but I think that would have same effect as renaming the plugin (change it to openmediavault-docker?) and adding a conflicts line to the control file.
-
I'm working on a "proof of concept" that I hope I will be able to complete and test tomorrow.
-
@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.
-
Hi,
Is it possible to set fix ip at 3.1.8 to access the service externally ?
thx
Barna
-
Have a look and see if this is something you could consider adding to the plugin.
That's fine with me. Can you submit a pull request?
-
@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.
-
Hi,
Is it possible to set fix ip at 3.1.8 to access the service externally ?
thx
Barna
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.
-
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
-
@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.
-
There have been other such changes before with packages called "docker" and "docker.io".
This is true, I do recall when this change came about. Unfortunately I was fresh into understanding and using docker at the time, so I probably wouldn't have known much better. To my understanding, I don't think the docker daemon process was changed/renamed though, I thought they simply modified the repository and package naming. The core commands and such were still called the same. My only worry here is that calling of the daemon will change. Thinking further though, I'd imagine it shouldn't change the commands being used in the core docker components, so I would hope this won't truly change anything other than the package naming. Obviously the package conflicts you mention are at the OS level and/or package level for installation more so than actual commands and daemon process calls.
I'll proceed with caution, but I think hopefully we should be good. I will try to see if those release notes do call out any gotchas in this regard. Thanks for the input! And thanks for the great plugin 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.
-
I have a very beginner level question. Is there a way to edit the docker run command that the plugin uses, or maybe that is not even needed for my situation.
I am using the below docker to perform background Handbrake jobs:
https://hub.docker.com/r/coppit/handbrake/
What I would like to do is add a specific command as described in the document to lower the priority of the handbrake encode. In the description it says:
Adding the flag --cap-add=SYS_NICE allows the container to run HandBrake at a lower priority.
My question is, where can I add this flag? Does it go in the extra arguments section, or somewhere else, and in what format?
Thank you in advance for your help and all the great work on this project.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!