b27f70d45a
The plugin spec says that plugins can live in one of: - /var/run/docker/plugins/<name>.sock - /var/run/docker/plugins/<name>/<name>.sock - /etc/docker/plugins/<name>.[json,spec] - /etc/docker/plugins/<name>/<name>.<json,spec> - /usr/lib/docker/plugins/<name>.<json,spec> - /usr/lib/docker/plugins/<name>/<name>.<json,spec> However, the plugin scanner which is used by the volume list API was doing `filepath.Walk`, which will walk the entire tree for each of the supported paths. This means that even v2 plugins in `/var/run/docker/plugins/<id>/<name>.sock` were being detected as a v1 plugin. When the v1 plugin loader tried to load such a plugin it would log an error that it couldn't find it because it doesn't match one of the supported patterns... e.g. when in a subdir, the subdir name must match the plugin name for the socket. There is no behavior change as the error is only on the `Scan()` call, which is passing names to the plugin registry when someone calls the volume list API. Signed-off-by: Brian Goff <cpuguy83@gmail.com> |
||
|---|---|---|
| .. | ||
| aaparser | ||
| archive | ||
| authorization | ||
| broadcaster | ||
| chrootarchive | ||
| containerfs | ||
| devicemapper | ||
| directory | ||
| discovery | ||
| dmesg | ||
| filenotify | ||
| fileutils | ||
| fsutils | ||
| homedir | ||
| idtools | ||
| ioutils | ||
| jsonmessage | ||
| locker | ||
| longpath | ||
| loopback | ||
| mount | ||
| namesgenerator | ||
| parsers | ||
| pidfile | ||
| platform | ||
| plugingetter | ||
| plugins | ||
| pools | ||
| progress | ||
| pubsub | ||
| reexec | ||
| signal | ||
| stdcopy | ||
| streamformatter | ||
| stringid | ||
| symlink | ||
| sysinfo | ||
| system | ||
| tailfile | ||
| tarsum | ||
| term | ||
| truncindex | ||
| urlutil | ||
| useragent | ||
| README.md | ||
pkg/ is a collection of utility packages used by the Moby project without being specific to its internals.
Utility packages are kept separate from the moby core codebase to keep it as small and concise as possible. If some utilities grow larger and their APIs stabilize, they may be moved to their own repository under the Moby organization, to facilitate re-use by other projects. However that is not the priority.
The directory pkg is named after the same directory in the camlistore project. Since Brad is a core
Go maintainer, we thought it made sense to copy his methods for organizing Go code :) Thanks Brad!
Because utility packages are small and neatly separated from the rest of the codebase, they are a good place to start for aspiring maintainers and contributors. Get in touch if you want to help maintain them!