Skip to content

Separate plugin sockets and specs.#13951

Merged
thaJeztah merged 1 commit intomoby:masterfrom
calavera:plugins_path
Jul 17, 2015
Merged

Separate plugin sockets and specs.#13951
thaJeztah merged 1 commit intomoby:masterfrom
calavera:plugins_path

Conversation

@calavera
Copy link
Contributor

Check if there is a plugin socket first under /run/docker/plugins/NAME.sock.
If there is no socket for a plugin, check /etc/docker/plugins/NAME.spec and
/usr/lib/docker/plugins/NAME.spec for spec files.

Fixes #13859

/cc @lukemarsden

Signed-off-by: David Calavera [email protected]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe we should mention per plugin directory here with a specific example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@proppy that's define at the bottom of this section, like 42. Is that good enough?

@cpuguy83
Copy link
Member

cpuguy83 commented Jul 1, 2015

Design LGTM

@LK4D4
Copy link
Contributor

LK4D4 commented Jul 1, 2015

@calavera What motivation behind separation unix sockets from specs?

@calavera
Copy link
Contributor Author

calavera commented Jul 2, 2015

@LK4D4 I think that's more where people expect to find them. Unix sockets under /run, like other unix sockets and specs under a "configuration" directory.

This is where we decided to go with this approach:

#13514 (comment)

@LK4D4
Copy link
Contributor

LK4D4 commented Jul 2, 2015

okay

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as I understand it, these changes leave the /usr/share path untested. is that accurate?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the /usr/share path is completely gone, we are not going to make this stable with that path.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, good to know.

On Jul 6, 2015, at 3:35 PM, David Calavera [email protected] wrote:

In integration-cli/docker_cli_start_volume_driver_unix_test.go #13951 (comment):

@@ -129,11 +129,11 @@ func (s *DockerExternalVolumeSuite) SetUpSuite(c *check.C) {
fmt.Fprintln(w, {})
})

  • if err := os.MkdirAll("/usr/share/docker/plugins", 0755); err != nil {
  • if err := os.MkdirAll("/etc/docker/plugins", 0755); err != nil {
    the /usr/share path is completely gone, we are not going to make this stable with that path.


Reply to this email directly or view it on GitHub https://github.com/docker/docker/pull/13951/files#r33990203.

@erikh
Copy link
Contributor

erikh commented Jul 6, 2015

LGTM other than the comments; but historically this stuff lives in /var/run -- is that a better place for it maybe?

@calavera calavera added the status/needs-attention Calls for a collective discussion during a review session label Jul 8, 2015
@calavera calavera added this to the 1.8.0 milestone Jul 8, 2015
@tomdee
Copy link
Contributor

tomdee commented Jul 9, 2015

Any update on this PR? Without it I'm unable to test network plugins on CoreOS.

And FWIW, I've been trying to test with this branch but I can't get it to work (with .sock files). I'm trying to create a network. i.e.

docker network create --driver=calico 0c6db1c987123
Error response from daemon: Plugin not found

The calico.sock file exists.

Does this change require a corresponding change to libnetwork?

@calavera
Copy link
Contributor Author

@tomdee I made a small change but it doesn't look to be the error you get. I don't think networking requires anything special. Can you point me to your code? This is my gluster plugin being used with this PR:

root@gfs-client-1:/# ./docker-1.8.0-dev run --volume-driver glusterfs --rm -it -v data-store:/data alpine:latest ash
/ # ls /data/
helo
root@gfs-client-1:/# ls -la /run/docker/plugins/glusterfs.sock
srw-rw---- 1 root root 0 Jul 10 04:29 /run/docker/plugins/glusterfs.sock
root@gfs-client-1:/#

@tomdee
Copy link
Contributor

tomdee commented Jul 13, 2015

I've retested this and it's working fine with Calico (as a libnetwork remote plugin) now. Either your small change did it, or I had a permission problem on the /run/docker directory.

I would love to see this merged ASAP - it would be great to start testing on CoreOS.

(And FWIW - anyone wanting to do manual testing of this - nc -lU /run/docker/plugins/test.sock is pretty handy for simulating a plugin. Running docker network create --driver test $RANDOM should produce output from the nc command if everything is getting wired up properly)

@abronan
Copy link
Contributor

abronan commented Jul 14, 2015

LGTM

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i know it's unrelated to this PR, but it's unfortunate we have another thing called Registry that has nothing to do with a docker registry :( we should consider renaming it to PluginService or PluginStore what do you think? Can be done in another PR, but just wanted to bring it to the attention

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I had the same feeling from the beginning, but naming is hard 😸

Let's think about something better somewhere else.

@tiborvass
Copy link
Contributor

LGTM

@thaJeztah
Copy link
Member

doc changes LGTM

Keep in mind that this is an experimental feature; docs only need a "casual" review, but are not part of the official documentation, so it's mostly important to make sure that the information is correct

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, thinking of this; perhaps you should mention in what order the directories are scanned, is that useful information?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a short explanation about the scan ordering.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@calavera
Copy link
Contributor Author

@thaJeztah the volume plugins are going in the 1.8 release. The docs will be moved to the right place after this lands on master. See #14659.

Check if there is a plugin socket first under `/run/docker/plugins/NAME.sock`.
If there is no socket for a plugin, check `/etc/docker/plugins/NAME.spec` and
`/usr/lib/docker/plugins/NAME.spec` for spec files.

Signed-off-by: David Calavera <[email protected]>
@thaJeztah
Copy link
Member

@calavera then I suggest to "dot the i's and cross the t's" in #14659. The right meta-data headers need to be added to the docs as well as part of that PR (and we can do some tweaking if needed)

@calavera
Copy link
Contributor Author

SGTM

@icecrime
Copy link
Contributor

I'm a bit confused here.

  • We're are merging this for 1.8
  • This impacts the docs
  • As per another PR, volume plugins are making it out of experimental
  • This other PR will hold the docs

Tentatively moving this to status/4-ready-to-merge assuming I got this right. Can you confirm @thaJeztah?

@thaJeztah
Copy link
Member

@icecrime IIUC, this not really touches the "docs" (as in, the docs here are still in the "experimental" directory). #14659 will promote this from "experimental" to "mainstream" and where the docs will be moved and touched-up to match the standards for the documentation.

So yes, I think ready to merge is good. @calavera also pinged Mary to have a look, but I think that can be done on #14659. So I'll merge so we can proceed 👍

thaJeztah added a commit that referenced this pull request Jul 17, 2015
Separate plugin sockets and specs.
@thaJeztah thaJeztah merged commit a763637 into moby:master Jul 17, 2015
@thaJeztah
Copy link
Member

@calavera merged!

@calavera calavera deleted the plugins_path branch July 17, 2015 19:35
tomdee added a commit to projectcalico/libcalico that referenced this pull request Jul 28, 2015
Requires moby/moby#13951


Former-commit-id: ef6f0896168dc7fd7bd514652ce6a73f66f837ec
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

status/needs-attention Calls for a collective discussion during a review session status/4-merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.