Update containerd to v1.2.8

[tao12345666333]

Signed-off-by: Jintao Zhang zhangjintao9020@gmail.com

- What I did
https://github.com/containerd/containerd/releases/tag/v1.2.8

full diff: containerd/containerd@85f6aa5...a4bc1d4

The eighth patch release for containerd 1.2 provides a series of bug fixes, many
of them backported from the master branch to correct several known issues around
manifest lists/indexes and pulling multi-arch, CVEs related to Golang/http2,
fd leakage in the Golang runtime, a shim hang, process and image environment config
handling, and finally mount cleanup related to Cloud Foundry's use of containerd
with rootless containers.

- Description for the changelog

Update containerd to v1.2.8

[tianon]

LGTM 🤘

[fuweid]

LGTM +1 lol

[thaJeztah]

Not sure I've seen this failure before: https://ci.docker.com/public/blue/rest/organizations/jenkins/pipelines/moby/branches/PR-39786/runs/1/nodes/34/log/?start=0

[2019-08-23T03:34:09.259Z] FAIL: docker_cli_daemon_test.go:588: DockerDaemonSuite.TestDaemonBridgeExternal
[2019-08-23T03:34:09.259Z] 
[2019-08-23T03:34:09.259Z] Creating a new daemon at: /go/src/github.com/docker/docker/bundles/test-integration/3/DockerDaemonSuite.TestDaemonBridgeExternal
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] waiting for daemon to start
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] exiting daemon
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] waiting for daemon to start
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] waiting for daemon to start
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] waiting for daemon to start
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] daemon started
[2019-08-23T03:34:09.259Z] 
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] Stopping daemon
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] daemon stop timeout
[2019-08-23T03:34:09.259Z] Attempt #2: daemon is still running with pid 8777
[2019-08-23T03:34:09.259Z] Attempt #3: daemon is still running with pid 8777
[2019-08-23T03:34:09.259Z] Attempt #4: daemon is still running with pid 8777
[2019-08-23T03:34:09.259Z] Attempt #5: daemon is still running with pid 8777
[2019-08-23T03:34:09.259Z] tried to interrupt daemon for 6 times, now try to kill it
[2019-08-23T03:34:09.259Z] [d8d56a5bd91d3] Error when stopping daemon: remove /go/src/github.com/docker/docker/bundles/test-integration/3/DockerDaemonSuite.TestDaemonBridgeExternal/d8d56a5bd91d3/docker.pid: no such file or directory
[2019-08-23T03:34:09.259Z] docker_cli_daemon_test.go:614:
[2019-08-23T03:34:09.259Z]     ...
[2019-08-23T03:34:09.259Z] /go/src/github.com/docker/docker/internal/test/daemon/daemon.go:442:
[2019-08-23T03:34:09.259Z]     t.Fatalf("Error while stopping the daemon %s : %v", d.id, err)
[2019-08-23T03:34:09.259Z] ... Error: Error while stopping the daemon d8d56a5bd91d3 : remove /go/src/github.com/docker/docker/bundles/test-integration/3/DockerDaemonSuite.TestDaemonBridgeExternal/d8d56a5bd91d3/docker.pid: no such file or directory
[2019-08-23T03:34:09.259Z]

No errors in the logs for that daemon, only;

time="2019-08-23T03:33:54.734768720Z" level=error msg="Force shutdown daemon"

d8d56a5bd91d3.log

[thaJeztah]

I'll restart Jenkins

[thaJeztah]

LGTM

[thaJeztah]

One failure, looks like a test is potentially flaky because it relies on time comparison;

TestVolumesInspect
[2019-08-23T17:19:00.510Z] --- FAIL: TestVolumesInspect (0.19s)
[2019-08-23T17:19:00.510Z]     volume_test.go:106: assertion failed: expression is false: createdAt.Truncate(time.Minute).Equal(now.Truncate(time.Minute)): CreatedAt (2019-08-23 17:18:59 +0000 UTC) not equal to creation time (2019-08-23 17:19:00.002229981 +0000 UTC m=+0.966333196)
[2019-08-23T17:19:00.510Z] === RUN   TestVolumesInvalidJSON
[2019-08-23T17:19:00.510Z] === RUN   TestVolumesInvalidJSON//volumes/create
[2019-08-23T17:19:00.510Z] === PAUSE TestVolumesInvalidJSON//volumes/create
[2019-08-23T17:19:00.510Z] === CONT  TestVolumesInvalidJSON//volumes/create
[2019-08-23T17:19:00.510Z] --- PASS: TestVolumesInvalidJSON (0.02s)
[2019-08-23T17:19:00.510Z]     --- PASS: TestVolumesInvalidJSON//volumes/create (0.00s)
[2019-08-23T17:19:00.510Z] FAIL

[tao12345666333]

One failure, looks like a test is potentially flaky because it relies on time comparison;

TestVolumesInspect
[2019-08-23T17:19:00.510Z] --- FAIL: TestVolumesInspect (0.19s)
[2019-08-23T17:19:00.510Z]     volume_test.go:106: assertion failed: expression is false: createdAt.Truncate(time.Minute).Equal(now.Truncate(time.Minute)): CreatedAt (2019-08-23 17:18:59 +0000 UTC) not equal to creation time (2019-08-23 17:19:00.002229981 +0000 UTC m=+0.966333196)
[2019-08-23T17:19:00.510Z] === RUN   TestVolumesInvalidJSON
[2019-08-23T17:19:00.510Z] === RUN   TestVolumesInvalidJSON//volumes/create
[2019-08-23T17:19:00.510Z] === PAUSE TestVolumesInvalidJSON//volumes/create
[2019-08-23T17:19:00.510Z] === CONT  TestVolumesInvalidJSON//volumes/create
[2019-08-23T17:19:00.510Z] --- PASS: TestVolumesInvalidJSON (0.02s)
[2019-08-23T17:19:00.510Z]     --- PASS: TestVolumesInvalidJSON//volumes/create (0.00s)
[2019-08-23T17:19:00.510Z] FAIL

@thaJeztah Should I modify the test case ? I can change it to compare if it is within 60s instead of comparing it to the same minute.

[thaJeztah]

@tao12345666333 yes, I think that would work 👍 (less than a minute would be ok as well; it's just the time between calling the create-request, and it actually completing, so should not differ more than 1..2 seconds under normal circumstances)