LGTM

But is there something wrong with the change or is Travis having issues?

But is there something wrong with the change or is Travis having issues?

hmm.... good one; I see one job is "cancelled" for some reason (not failed). My previous PR took a very long time before it got scheduled, so perhaps there's something with travis?

Disclaimer: I can't exclude that there's something with my changes (e.g. if the CRIU bump wasn't good for this branch), so let's make sure it does a full run of CI 👍

hm.. is this a known issue, or introduced by my changes?

Test Suite Failed
--- FAIL: TestCRISuite (0.28s)
    cri_test.go:122: Failed to run tests in paralllel: exit status 1
FAIL

time="2019-04-02T04:07:31Z" level=info msg="Start snapshots syncer" 
time="2019-04-02T04:07:31Z" level=info msg="Start streaming server" 
time="2019-04-02T04:07:31Z" level=error msg="Failed to start streaming server" error="listen tcp 10.20.11.20:10010: bind: address already in use" 
time="2019-04-02T04:07:31Z" level=info msg="Stop CRI service" 
time="2019-04-02T04:07:31Z" level=info msg="Event monitor stopped" 
time="2019-04-02T04:07:31Z" level=info msg="Stream server stopped" 
time="2019-04-02T04:07:31Z" level=fatal msg="Failed to run CRI service" error="stream server error: listen tcp 10.20.11.20:10010: bind: address already in use" 

Looks indeed unrelated #2577 (comment)

I'm a bit confused though, as I'm not able to find that file, nor the test (TestCRISuite)

Ah found it; https://github.com/kubernetes-sigs/cri-tools/blob/34b50d873a66e073d6a9ddc3961a917df05dc15d/cmd/critest/cri_test.go#L125-L142

Looks like @Random-Liu had a PR to fix parallel tests kubernetes-sigs/cri-tools#273. Looks like that's already included in this branch though; https://github.com/kubernetes-sigs/cri-tools/blame/v1.0.0-beta.1/pkg/framework/util.go#L66-L71

I think you are getting caught by the StreamServer* settings that changed in the CRI plugin:
release/1.1:

./vendor/github.com/containerd/cri/pkg/config/config.go:139:            StreamServerAddress:     "",
./vendor/github.com/containerd/cri/pkg/config/config.go:140:            StreamServerPort:        "10010",

master:

./vendor/github.com/containerd/cri/pkg/config/config.go:197:            StreamServerAddress: "127.0.0.1",
./vendor/github.com/containerd/cri/pkg/config/config.go:198:            StreamServerPort:    "0",

It could be that by changing the underlying Ubuntu release in the Travis config, there is now a service actually listening on 10010 that didn't exist in the older Ubuntu image? I don't believe you are hitting any issue with parallel containerd runs, as the containerd socket already in use would be hit before the CRI streaming server issue, which is what the latest Travis run shows:

time="2019-04-02T04:05:27Z" level=info msg="Start streaming server" 
time="2019-04-02T04:05:27Z" level=error msg="Failed to start streaming server" error="listen tcp 10.20.11.20:10010: bind: address already in use" 
time="2019-04-02T04:05:27Z" level=info msg="Stop CRI service" 

Hm. Good call; wasn't that actually a bug / undesired situation (the stream server being enabled by default instead of opt-in?). Wondering if that change would have to be backported to 1.1

Hm... change was in moby; moby/moby#37519, let me dig further what was discussed in containerd

Change in containerd/cri was containerd/cri#858

@Random-Liu do you think that should be backported to the containerd/cri 1.1 branch, or would that be a breaking change?

any update here? @thaJeztah and @Random-Liu

Going to close this for now until we figureout if we are going to backport cri changes or not