I saw a failure of TestDockerCmdWithTimeout. This test starts a command
that produces output after 10 ms, but uses a 5 ms timeout, so normally
the command will be killed before the output. The time intervals are so
small that the timeout may not reliably trigger before the output, which
can cause the test to fail.
This commit changes the test to only fail if the process is still alive
after 10 seconds. This means the test will confirm that the timeouts are
happening, but not attempt to gauge that the timeouts are happening
within milliseconds of when they are expected (which can't be done
reliably).
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 13d768b8ee05d3158c62d761e4ebe657cd7a8c25
Component: engine
Following `docker inspect` conventions:
- Keep partial info in a buffer to not print incomplete template outputs.
- Break execution when template parsing or decoding fail.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: b9d30280f6eb2f817b1315c22953a133f1b66e69
Component: engine
So other packages don't need to import the daemon package when they
want to use this struct.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: 6bb0d1816acd8d4f7a542a6aac047da2b874f476
Component: engine
A TopicFunc is an interface to let the pubisher decide whether it needs
to send a message to a subscriber or not. It returns true if the
publisher must send the message and false otherwise.
Users of the pubsub package can create a subscriber with a topic
function by calling `pubsub.SubscribeTopic`.
Message delivery has also been modified to use concurrent channels per
subscriber. That way, topic verification and message delivery is not
o(N+M) anymore, based on the number of subscribers and topic verification
complexity.
Using pubsub topics, the API stops controlling the message delivery,
delegating that function to a topic generated with the filtering
provided by the user. The publisher sends every message to the
subscriber if there is no filter, but the api doesn't have to select
messages to return anymore.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 434d2e8745696255a204d9eefc6a2854ff74e5c2
Component: engine
…for consistency as docker inspect and docker volume inspect supports it too
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 295c27388dd1e7cc4196fbb8ffe0646b33bacb5b
Component: engine
Some users expect that the `docker top $CONT` command displays information from the inside container perspective.
They expect that the `docker top $CONT` command displays same information as the `docker exec $CONT ps -ef` command. But it does not.
That's why the `docker top` man page shall explicitly state that the `docker top $CONT` displays information from the host's point of view.
Signed-off-by: Pavel Pospisil <pospispa@gmail.com>
Upstream-commit: 1edc410e412b9c06869e508f5781cd2cdc0a14af
Component: engine
modified note to provide a link for installation instructions on Ubuntu 15.04 or above
cleaned up typos for ubuntulinux.md
Signed-off-by: Zuhayr Elahi <elahi.zuhayr@gmail.com>
Upstream-commit: 0fb1845e957353792b39475751221d1b8b66da52
Component: engine
Improves the current filtering implementation complixity.
Currently, the best case is O(N) and worst case O(N^2) for key-value filtering.
In the new implementation, the best case is O(1) and worst case O(N), again for key-value filtering.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 93d1dd8036d57f5cf1e5cbbbad875ae9a6fa6180
Component: engine
