Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

attach: Use ContainerWait instead of Inspect #696

Merged
merged 2 commits into from
Jan 20, 2018

Conversation

mlaventure
Copy link
Contributor

Signed-off-by: Kenfe-Mickael Laventure mickael.laventure@gmail.com

--

Addresses moby/moby#35497

- What I did

Use ContainerWait() instead of Inspect to retrieve the final exit code in atach

- How I did it

Changed the code ;-)

- How to verify it

$ docker run -f --name exit alpine sh -c 'sleep 10; exit 21'
$ docker attach exit
$ echo $?
21

- Description for the changelog

Ensure attach exit code matches container's

- A picture of a cute animal (not mandatory but encouraged)
🐶

Copy link
Contributor

@dnephin dnephin left a comment

Choose a reason for hiding this comment

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

Change looks good, but there are test and lint failure

Would you mind writing a TestAttach in e2e/container/attach_test.go ?

@mlaventure
Copy link
Contributor Author

Sure, will give it a go

@@ -66,6 +66,9 @@ func runAttach(dockerCli command.Cli, opts *attachOptions) error {
ctx := context.Background()
client := dockerCli.Client()

// request channel to wait for client
resultC, errC := client.ContainerWait(ctx, opts.container, "")
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, actually I think this should come after inspectContainerAndCheckState() which is a sanity check on the state of the container.

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 wanted to avoid a race when by the time we return from inspectContainerAndCheckState() the container had exited, but I don't mind moving it afterwards.

Copy link
Contributor

Choose a reason for hiding this comment

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

good point, maybe it is more correct before the inspect. The error from ContainerWait() wouldn't be reported until later, so the user would still see the helpful error message.

I think this is correct, ignore my comment.

@mlaventure mlaventure force-pushed the attach-use-containerwait branch 2 times, most recently from 864ba8b to 992c9ee Compare November 17, 2017 16:13
@codecov-io
Copy link

codecov-io commented Nov 17, 2017

Codecov Report

Merging #696 into master will decrease coverage by 0.67%.
The diff coverage is 93.75%.

@@            Coverage Diff            @@
##           master    #696      +/-   ##
=========================================
- Coverage   51.28%   50.6%   -0.68%     
=========================================
  Files         216     216              
  Lines       17743   17728      -15     
=========================================
- Hits         9099    8972     -127     
- Misses       8175    8304     +129     
+ Partials      469     452      -17

@mlaventure
Copy link
Contributor Author

I'm not sure what to do about the gocyclo complain. I don't want to make a function just because of it. So if we don't want to raise the limit, I would need to think of a way of refactoring the would function.

Regarding the test failure, it is very strange, it looks like we do get the output, but don't notice that the process is dead? I haven't been able to reproduce it locally.

@@ -140,7 +143,18 @@ func runAttach(dockerCli command.Cli, opts *attachOptions) error {
if errAttach != nil {
return errAttach
}
return getExitStatus(ctx, dockerCli.Client(), opts.container)

// get status code
Copy link
Contributor

@dnephin dnephin Nov 17, 2017

Choose a reason for hiding this comment

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

This seems like a perfect place to create a new function. A function is always better than an inline comment as it provides a scope for the documentation.

I think the unit test you removed could be preserved and used to test the function, with a few small changes to the test setup. The 3 cases in the table test are still relevant.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It feels weird given that it's really just a select, the comment could be removed without affecting readability, but I'll try that.

cmd := icmd.Command("docker", "wait", cName)
res := icmd.StartCmd(cmd)
icmd.RunCommand("docker", "attach", cName).Assert(t, icmd.Expected{ExitCode: 21})
icmd.WaitOnCmd(8, res).Assert(t, icmd.Expected{ExitCode: 0, Out: "21"})
Copy link
Contributor

Choose a reason for hiding this comment

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

This is only waiting 8ms, I'm not sure if that's related to the failure.

I'll see if I can get this working

Copy link
Contributor

Choose a reason for hiding this comment

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

This test fails for me locally as well so I'll prepare a patch to get it working.

I think the docker wait command is unnecessary, all we need is a poll.WaitOn() for the container to be started.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Didn't realize it was in ms 😅

Thanks poll.WaitOn() seems to be what I was looking for. I'll try updating the code tonight.

Copy link
Contributor

Choose a reason for hiding this comment

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

I pushed a commit, it seems to be working now. I didn't use the WaitOn for container start. I'm not sure if this test can flake, maybe runBackgroundContainsWithExitCode() could use a WaitOn if we see it flake.

@dnephin
Copy link
Contributor

dnephin commented Nov 17, 2017

I pushed a commit to this branch which I think will fix the e2e suite.

Edit: build didn't trigger on jenkins for some reason, so I forced a run from jenkins ui

Edit: it's green!

@mlaventure mlaventure force-pushed the attach-use-containerwait branch 2 times, most recently from 361354c to e84bf6c Compare November 18, 2017 01:43
mlaventure and others added 2 commits November 17, 2017 18:12
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
@mlaventure
Copy link
Contributor Author

All green 💚

Copy link
Contributor

@dnephin dnephin left a comment

Choose a reason for hiding this comment

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

LGTM

@thaJeztah thaJeztah added this to the 17.12.0 milestone Nov 30, 2017
@tonistiigi
Copy link
Member

What caused this change? Was there a problem in all previous versions or did the API change? The linked issue seems like a regression.

@mlaventure
Copy link
Contributor Author

From my understanding of the code, the race was always here, is just that a bit more of the post processing has been moved to the event handler now and increased the latency.

@tonistiigi
Copy link
Member

LGTM

@thaJeztah thaJeztah removed this from the 17.12.0 milestone Jan 20, 2018
@thaJeztah
Copy link
Member

Looks like we have 2 LGTM's; merging

@thaJeztah thaJeztah merged commit 44a1168 into docker:master Jan 20, 2018
@GordonTheTurtle GordonTheTurtle added this to the 18.02.0 milestone Jan 20, 2018
@andrewhsu
Copy link
Contributor

FYI this PR don't play nice with latest code from moby/moby in docker-ce 18.02.0 rc1. Getting failures like:

panic: DockerSuite.TestAttachAfterDetach test timed out after 5m0s [recovered]
	panic: DockerSuite.TestAttachAfterDetach test timed out after 5m0s

Reverting the changes in this PR and stuff goes green.

@dnephin
Copy link
Contributor

dnephin commented Jan 31, 2018

That test seems to have a 2s timeout for attach so I'm not sure how it's failing this way. I'll investigate

@dnephin
Copy link
Contributor

dnephin commented Feb 20, 2018

Seems to be an issue with the test, Opened moby/moby#36363

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants