oh man... I'd punt on this. Don't see why anyone would really need to customize this other than "look ma, I can customize things".

@cpuguy83 I totally agree with you, but I'm sure if we don't do it someone else will. To be clear, I'm okay with closing this PR and forgetting about it.

@cpuguy83 I just thought about a case where we'll want to change this, windows 😉

Moving forward with this after a rebase.

@calavera In that case it's just a constant set in an _windows.go file :)

that's very true.

Not sure about this either; is there an actual use case already? If not, then I wonder if we should add it just because it may become handy.

Just my 0.02

Okay, I'm sold, closing this PR.

Reopening this because of #13859

Maybe we should make /var/lib/docker default? :)

For my normal testing, I start the Docker daemon with docker -d -D -g /data/docker - which is really its own mounted partition.

rather than hard coding the default to /var/lib/docker, perhaps it would be useful to default to {graphdir}/plugins.

however, I then note another pain point - the plugin API does not communicate daemon settings to it - so it doesn't know that in this case, it should probably make the the mounts in /data/docker.

tbh, I'm hoping the daemon can pass on some more client oriented info too, but that may be pushing it :)

@SvenDowideit it cannot go into {graphdir}/plugins. We already had that discussion, as @tianon pointed out, the drivers expect a defined structure.

Also, keep in mind that /var/lib/docker is meant to be ephemeral. You can always wipe out the directory, run docker run container and everything works. If we put the plugins directory there, that directory stops being ephemeral, because you'll want to save the plugins configuration.

Based on the plugins docs it seems that the plugins are either a unix socket or a spec file pointing to a unix socket (why not a symlink?). The accepted pattern for IPC unix sockets is to put them into /run/. So, I would suggest that the plugins be a combination of three locations:

/run/docker/plugins
/etc/docker/plugins
/usr/lib/docker/plugins

And have an inheritance order where /run overrides /etc and /etc overrides /usr on name collision. I would also suggest that both /etc and /usr only be allowed to contain spec files.

cc @icecrime

Sounds legit to me.
I don't like configurable plugin paths at all.

Sounds like a good idea to me too, I'll make the changes here and update the title to reflect that.

Closing. I'm going to start over in a new pull request.