make unitfile independent of docker.service

[lsm5]

This allows both docker and docker-latest to use lvm-plugin without any changes in lvm-plugin's unitfile.

Instead docker and docker-latest's unitfiles will have a dependency on docker-lvm-plugin like so:

After=docker-lvm-plugin.socket

Signed-off-by: Lokesh Mandvekar lsm5@fedoraproject.org

[lsm5]

@rhatdan @runcom ptal

[rhatdan]

How do we guarantee that docker-lvm-plugin is started before docker or docker-latest?

[rhatdan]

Could we make docker-latest.service be a provider of the docker.service?

Alias=: This directive allows the unit to be enabled under another name as well. Among other uses, this allows multiple providers of a function to be available, so that related units can look for any provider of the common aliased name.

[shishir-a412ed]

IIUC, we are talking two separate things here right ?

1) Define an Alias in the unit file for docker.service would basically instruct systemd to create symbolic links at installation time, this would allow a user to start docker with different names. So this is a PR to docker/docker or projectatomic/docker ?

2) Making sure that docker-lvm-plugin starts before docker. @lsm5 fixes this.

Shishir

[rhatdan]

Well we want docker-latest.service to be started if a user requests docker.service, I guess, or better yet create a docker-engine.service and have both of them create it when a user enables docker-latest. then you could have docker-lvm-plugin rely on

[rhatdan]

Lets change docker-latest.service to do this, after light testing this seems to work correctly

 diff -u /lib/systemd/system/docker.service /lib/systemd/system/docker-latest.service
--- /lib/systemd/system/docker.service  2016-08-09 09:16:23.426594094 -0400
+++ /lib/systemd/system/docker-latest.service   2016-08-09 09:16:15.422640704 -0400
@@ -31,3 +31,4 @@

 [Install]
 WantedBy=multi-user.target
+Alias=docker.service

[lsm5]

Dan, I don't see why we would want to start docker-latest.service if a user requests docker.service.

We leave it to the user to choose between docker.service and docker-latest.service and they're always run either-or.

[rhatdan]

Right this has nothing to do with docker-latest versus docker. The user starts one service. But docker-latest is providing a docker service as far as the system is concerned. So if I have a unit that relies on the docker-service running or not running, we want docker-latest to claim that it is the docker.service.

That is what alias does. Think of it like an RPM provides.

[lsm5]

Dan, I'll modify this PR to include your changes in a bit.

[lsm5]

Dan, if we're going the alias route, I think we should still keep plugin unitfiles independent of docker and add the alias in docker-latest.service like you mentioned. IIUC, you wanted to make plugins independent of docker in future, but maybe I misinterpreted??

[rhatdan]

If you have the aliases then the plugins can start using the Before docker.service, then if you install the docker-latest of the docker package it will install a docker.service

IE:

systemctl install docker-latest will provide the docker.service that the docker plugins require.

[shishir-a412ed]

@rhatdan @lsm5 Do we still need this or can we close this one?

[rhatdan]

If this is that old, I think you can safely close it.

BTW we will be working on podman volume support, it would be nice to see if we could get podman to work with the docker-lvm-plugin.

[shishir-a412ed]

@rhatdan Sure, let me take a look at podman and check how it manages volumes.