This appears to be a remnant from the CLI that is no longer imported
anywhere. Remove it from vendor.conf and the vendor directory.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
The current use of the types from distribution brings in some
unfortunate dependencies, including other distribution packages and the
gorilla/mux and gorilla/context packages. Using the OCI types avoids
the extra dependencies for client users.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Changes are:
$ git log --no-merges --oneline 19220953c4a4..c56e08229111
4b76270 Keep "vendor.conf" for reference
ac8f766 travis: update to go 1.8.1
c196644 Better validation of duplicates
e684d5e check for unused packages at the end
3ed2513 detect default gopath($HOME/go)
c9052f3 fix backtick in readme
0e04f23 Missing installation section in README
Changes to moby are the inclusion of several upstream vendor.conf files and
switching to vendoring the toplevel golang.org/x/sync package rather than the
syncmap sub-package due to:
2017/05/02 11:21:06 WARNING: package golang.org/x/sync/syncmap is not root import, should be golang.org/x/sync
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Container state counts are used for reporting in the `/info` endpoint.
Currently when `/info` is called, each container is iterated over and
the containers 'StateString()' is called. This is not very efficient
with lots of containers, and is also racey since `StateString()` is not
using a mutex and the mutex is not otherwise locked.
We could just lock the container mutex, but this is proven to be
problematic since there are frequent deadlock scenarios and we should
always have the `/info` endpoint available since this endpoint is used
to get general information about the docker host.
Really, these metrics on `/info` should be deprecated. But until then,
we can just keep a running tally in memory for each of the reported
states.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Logging plugins use the same HTTP interface as other plugins for basic
command operations meanwhile actual logging operations are handled (on
Unix) via a fifo.
The plugin interface looks like so:
```go
type loggingPlugin interface {
StartLogging(fifoPath string, loggingContext Context) error
StopLogging(fifoPath)
```
This means a plugin must implement `LoggingDriver.StartLogging` and
`LoggingDriver.StopLogging` endpoints and be able to consume the passed
in fifo.
Logs are sent via stream encoder to the fifo encoded with protobuf.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
