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

TestPostContainersAttach: minor improvements #36612

Merged
merged 1 commit into from
May 8, 2018

Conversation

kolyshkin
Copy link
Contributor

@kolyshkin kolyshkin commented Mar 16, 2018

The API part of this test (the last test case in TestPostContainerAttach) is flaky, i.e. it sometimes fails on powerpc or s390 like this:

> FAIL: docker_api_attach_test.go:98: DockerSuite.TestPostContainersAttach
> docker_api_attach_test.go:211:
>     c.Assert(actualStdout.Bytes(), checker.DeepEquals, []byte("hello\nsuccess"), check.Commentf("Attach didn't return the expected data from stdout"))
> ... obtained []uint8 = []byte{0x73, 0x75, 0x63, 0x63, 0x65, 0x73, 0x73}
> ... expected []uint8 = []byte{0x68, 0x65, 0x6c, 0x6c, 0x6f, 0xa, 0x73, 0x75, 0x63, 0x63, 0x65, 0x73, 0x73}
> ... Attach didn't return the expected data from stdout

Is seems that "success" is returned but "hello\n" is not (as if ContainerAttachOptions.Logs was false).

After a careful code audit I still can't figure out why it fails. The two major differences from the other cases are:

  • it uses API (ContainerAttach()) rather than sockRequestHijack();
  • it uses stdcopy.StdCopy() not io.ReadFull(),

Nevertheless it looks almost legit, except for ignoring the error from StdCopy. So I don't know how to fix it. Still, there are some things that can be improved here, including:

  1. Get the container's stderr as well, make sure it's empty.

  2. Check that stdcopy.StdCopy() did not return an error.

  3. Use strings, so the test output will be more readable.

  4. Nitpicks; move/remove comments, simplify var names.

This should ultimately fix #36611

@codecov
Copy link

codecov bot commented Mar 16, 2018

Codecov Report

❗ No coverage uploaded for pull request base (master@185ae7e). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master   #36612   +/-   ##
=========================================
  Coverage          ?   35.08%           
=========================================
  Files             ?      615           
  Lines             ?    45780           
  Branches          ?        0           
=========================================
  Hits              ?    16062           
  Misses            ?    27611           
  Partials          ?     2107

@thaJeztah
Copy link
Member

@kolyshkin could this have any relation to #36517 ?

@kolyshkin kolyshkin changed the title [do not merge] TestPostContainerAttach: improve the API part [do not merge] TestPostContainersAttach: improve the API part Mar 16, 2018
@kolyshkin
Copy link
Contributor Author

OK, the amended test revealed the error is returned from StdRead (that was previously ignored):

docker_api_attach_test.go:212:
    c.Assert(err, checker.IsNil)
... value *net.OpError = &net.OpError{Op:"read", Net:"unix", Source:(*net.UnixAddr)(0xc423f66680), Addr:(*net.UnixAddr)(0xc423f666a0), Err:(*poll.TimeoutError)(0x28347a0)} ("read unix @->/go/src/github.com/docker/docker/bundles/test-integration/docker.sock: i/o timeout")

@GordonTheTurtle GordonTheTurtle added the dco/no Automatically set by a bot when one of the commits lacks proper signature label Mar 16, 2018
@GordonTheTurtle GordonTheTurtle removed the dco/no Automatically set by a bot when one of the commits lacks proper signature label Mar 16, 2018
@kolyshkin
Copy link
Contributor Author

@kolyshkin could this have any relation to #36517 ?

It certainly might; let's see if reverting it will help

@kolyshkin
Copy link
Contributor Author

OK, two rounds with commit 3798392 ("Ensure a hijacked connection implements CloseWrite whenever its underlying") reverted shows no failures (with my modified test). It's still not too many runs though.

Let's try without the revert now.

@kolyshkin
Copy link
Contributor Author

Win CI timed out, experimental has some unrelated failures. I am currently out of ideas for this one.

@tonistiigi
Copy link
Member

@kolyshkin FYI #36663

@kolyshkin
Copy link
Contributor Author

kolyshkin commented Mar 22, 2018

@kolyshkin FYI #36663

@tonistiigi thanks! Also, the intermittent nature of the test case failure is explained by whether there's something in the buffer; if it is empty (which in our CI sometimes happens on slower hardware) the hijackedConnCloseWriter is not performed. Update: it is vise versa?

@kolyshkin kolyshkin changed the title [do not merge] TestPostContainersAttach: improve the API part TestPostContainersAttach: minor improvements Mar 26, 2018
@coolljt0725
Copy link
Contributor

ping @thaJeztah @tonistiigi @vdemeester

@moby moby deleted a comment from GordonTheTurtle Apr 3, 2018
Copy link
Member

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

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

LGTM 🐯

c.Assert(actualStdout.Bytes(), checker.DeepEquals, []byte("hello\nsuccess"), check.Commentf("Attach didn't return the expected data from stdout"))
var outBuf, errBuf bytes.Buffer
_, err = stdcopy.StdCopy(&outBuf, &errBuf, resp.Reader)
if errors.Cause(err).(net.Error).Timeout() {
Copy link
Member

Choose a reason for hiding this comment

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

This would panic if err is nil, is that an issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, thank you, I have updated the commit

Copy link
Member

@boaz0 boaz0 left a comment

Choose a reason for hiding this comment

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

LGTM 👍

When this test fails, the error looks like this:

> FAIL: docker_api_attach_test.go:98: DockerSuite.TestPostContainersAttach
> docker_api_attach_test.go:211:
>     c.Assert(actualStdout.Bytes(), checker.DeepEquals, []byte("hello\nsuccess"), check.Commentf("Attach didn't return the expected data from stdout"))
> ... obtained []uint8 = []byte{0x73, 0x75, 0x63, 0x63, 0x65, 0x73, 0x73}
> ... expected []uint8 = []byte{0x68, 0x65, 0x6c, 0x6c, 0x6f, 0xa, 0x73, 0x75, 0x63, 0x63, 0x65, 0x73, 0x73}
> ... Attach didn't return the expected data from stdout

Let's use strings for comparisons to make the output more readable.

While at it,
- get the container's stderr as well, and make sure it's empty;
- check that stdcopy.StdCopy() did not return an error, except for
  the timeout which is expected;
- move/remove comments, simplify var names.

Signed-off-by: Kir Kolyshkin <[email protected]>
Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

LGTM

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.

flaky test integration-cli/DockerSuite.TestPostContainersAttach()
8 participants