Conversation
119fb19 to
b4532ac
Compare
|
@WeiZhang555 @cpuguy83 any concerns for the approach? |
b4532ac to
f344448
Compare
|
The design looks good, I like it :-) |
|
@WeiZhang555 Indeed, however we still need to support old daemons. |
f344448 to
4d72b20
Compare
|
@cpuguy83 Yep, you're right, then we have to keep both |
|
Well, at least |
bf5dbce to
0a3032b
Compare
0348904 to
c8cf3fa
Compare
|
I've removed the [WIP] label from this PR and made the necessary changes to the API client and docs. Please take a look. I've also updated the While all of the integration tests pass locally for me, I have seen some flakiness in a few tests that Jenkins runs. They mostly get this error: But I can't tell if it's related to my changes or not since I tried not to modify container state/lifecycle in any way. |
cli/command/container/utils.go
Outdated
There was a problem hiding this comment.
Oops, I forgot to do statusC <- 125 here.
64f354d to
a43fd26
Compare
dnephin
left a comment
There was a problem hiding this comment.
LGTM
A bit light on tests, but I guess we can address that later.
Are all 12 commits still relevant? Do you think some of them could be squashed now that this is ready to merge?
This patch consolidates the two WaitStop and WaitWithContext methods on the container.State type. Now there is a single method, Wait, which takes a context and a bool specifying whether to wait for not just a container exit but also removal. The behavior has been changed slightly so that a wait call during a Created state will not return immediately but instead wait for the container to be started and then exited. The interface has been changed to no longer block, but instead returns a channel on which the caller can receive a *StateStatus value which indicates the ExitCode or an error if there was one (like a context timeout or state transition error). These changes have been propagated through the rest of the deamon to preserve all other existing behavior. Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn)
This patch adds the untilRemoved option to the ContainerWait API which allows the client to wait until the container is not only exited but also removed. This patch also adds some more CLI integration tests for waiting for a created container and waiting with the new --until-removed flag. Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Handle detach sequence in CLI Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Update Container Wait Conditions Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Apply container wait changes to API 1.30 The set of changes to the containerWait API missed the cut for the Docker 17.05 release (API version 1.29). This patch bumps the version checks to use 1.30 instead. This patch also makes a minor update to a testfile which was added to the builder/dockerfile package. Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Remove wait changes from CLI Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Address minor nits on wait changes - Changed the name of the tty Proxy wrapper to `escapeProxy` - Removed the unnecessary Error() method on container.State - Fixes a typo in comment (repeated word) Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Use router.WithCancel in the containerWait handler This handler previously added this functionality manually but now uses the existing wrapper which does it for us. Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Add WaitCondition constants to api/types/container Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Address more ContainerWait review comments - Update ContainerWait backend interface to not return pointer values for container.StateStatus type. - Updated container state's Wait() method comments to clarify that a context MUST be used for cancelling the request, setting timeouts, and to avoid goroutine leaks. - Removed unnecessary buffering when making channels in the client's ContainerWait methods. - Renamed result and error channels in client's ContainerWait methods to clarify that only a single result or error value would be sent on the channel. Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Move container.WaitCondition type to separate file ... to avoid conflict with swagger-generated code for API response Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn) Address more ContainerWait review comments Docker-DCO-1.1-Signed-off-by: Josh Hawn <[email protected]> (github: jlhawn)
ec867d4 to
4921171
Compare
|
Rebased and squashed, it's now just 2 commits. |
|
Thanks! |
|
All 💚 |
|
The CLI changes are now in a PR against the |
1. As daemon.ContainerStop() documentation says, > If a negative number of seconds is given, ContainerStop > will wait for a graceful termination. but since commit cfdf84d (PR moby#32237) this is no longer the case. This happens because `context.WithTimeout(ctx, timeout)` is implemented as `WithDeadline(ctx, time.Now().Add(timeout))`, resulting in a deadline which is in the past. To fix, don't use WithDeadline() if the timeout is negative. 2. Add a test case to validate the correct behavior and as a means to prevent a similar regression in the future. 3. Fix/improve daemon.ContainerStop() and client.ContainerStop() description for clarity and completeness. 4. Fix/improve DefaultStopTimeout description. Fixes: cfdf84d ("Update Container Wait") Signed-off-by: Kir Kolyshkin <[email protected]>
Summary
The goal for this PR is to be able to use the
POST /containers/{name}/waitAPI in order to no longer rely on the Events API when doingdocker run ...anddocker startin attached mode. Here is the set of behavioral changes in the API and CLI:The wait API now has on optional query parameter,
condition, which specifies the state of the container which the client would like to wait for:not-runningThis is the default value which maintains the existing behavior of the Wait API. It blocks if the container is in a state which is considered to be running, i.e., any of running, paused, or restarting. If it is already not in any of those states, then it would not block at all and return immediately with the current exit code.
next-exitThis condition allows the client to wait for the container's state to change to a not-running state or to be removed. This is different from the not-running option because it will block if the container is in the created, exited, dead, or removing state, blocking through a transition to one of the running states and back to one of exited states or until the container is removed, whichever comes first. It is similar to waiting for a die or destroy event. This option is very useful to use before issuing a container start API request.
removedThis condition allows the client to wait for the container to be removed. It is similar to waiting for a destroy event.
The Wait API will now return HTTP response headers immediately. This serves an an acknowledgement that a wait has been registered. The JSON response body will not be returned until the wait condition is met.
The Wait API's request context is extended to wait for a
http.CloseNotifierevent in the case that the client closes the connection while the server is blocked on the wait condition. This prevents leaked goroutines but should only be necessary until we switch to using Go 1.8's request context which cancels automatically if the client disconnects.To handle a manual detach (when the user enters the detach keys sequence when attached in TTY mode), the CLI now detects this key sequence, stops sending stdin, and causes the CLI to exit immediately. This is done as an alternative to waiting for a detach event.The rug has been pulled out from under this bullet point. This will have to be done in the github.com/docker/cli repo along with the other CLI changes.Follow-up to #31794
Fixes #32242