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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Containerd 1.0 client #34895

Merged
merged 3 commits into from Oct 23, 2017

Conversation

@mlaventure
Contributor

mlaventure commented Sep 19, 2017

- What I did

Replaced containerd v0.2.x with v1.0

- How I did it

Refactored libcontainerd

- How to verify it

CI must be green

- Description for the changelog

Move to containerd v1.0

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

馃惣

--

What's not finished

  • Checkpoint backward compatibility (there seem to be no test in CI)
  • Some cleanup is needed. I've kept the code that is supposed to make it work on windows via containerd around for now, would probably be better to remove it and redo it later.

Closes #34662

// DefaultRuntimeName is the default runtime to be used by
// containerd if none is specified
DefaultRuntimeName = "docker-runc"

This comment has been minimized.

@AkihiroSuda

AkihiroSuda Sep 19, 2017

Member

How differs from DefaultRuntimeBinary?

@AkihiroSuda

AkihiroSuda Sep 19, 2017

Member

How differs from DefaultRuntimeBinary?

This comment has been minimized.

@mlaventure

mlaventure Oct 3, 2017

Contributor

This is the name used for the --runtime option map

@mlaventure

mlaventure Oct 3, 2017

Contributor

This is the name used for the --runtime option map

@@ -56,6 +51,21 @@ func (daemon *Daemon) FillPlatformInfo(v *types.Info, sysInfo *sysinfo.SysInfo)
v.RuncCommit.ID = "N/A"
}
v.ContainerdCommit.Expected = dockerversion.ContainerdCommitID
if rv, err := exec.Command("docker-containerd", "--version").Output(); err == nil {

This comment has been minimized.

@AkihiroSuda

AkihiroSuda Sep 19, 2017

Member

Can we let docker-containerd --version print JSON?

@AkihiroSuda

AkihiroSuda Sep 19, 2017

Member

Can we let docker-containerd --version print JSON?

This comment has been minimized.

@mlaventure
@mlaventure

This comment has been minimized.

@AkihiroSuda
@AkihiroSuda
@mlaventure

This comment has been minimized.

Show comment
Hide comment
@mlaventure

mlaventure Sep 20, 2017

Contributor
unable to remove filesystem for ce4f7a31758fb7bd47c91f6210a2e768c4dfe32876109e4df87d6d7f47622f6d: remove /var/lib/docker/containers/ce4f7a31758fb7bd47c91f6210a2e768c4dfe32876109e4df87d6d7f47622f6d/shm: device or resource busy

Those errors are fixed when upgrading the kernel pass 3.13, could we upgrade CI to something a bit more recent? The lts kernel in trusty is 4.4.0 now (cc @andrewhsu)

Contributor

mlaventure commented Sep 20, 2017

unable to remove filesystem for ce4f7a31758fb7bd47c91f6210a2e768c4dfe32876109e4df87d6d7f47622f6d: remove /var/lib/docker/containers/ce4f7a31758fb7bd47c91f6210a2e768c4dfe32876109e4df87d6d7f47622f6d/shm: device or resource busy

Those errors are fixed when upgrading the kernel pass 3.13, could we upgrade CI to something a bit more recent? The lts kernel in trusty is 4.4.0 now (cc @andrewhsu)

@allencloud

This comment has been minimized.

Show comment
Hide comment
@allencloud

allencloud Sep 22, 2017

Contributor

Hi, @mlaventure Thanks for your work very much.
While here I have a question for the change of containerd's version. After all, it is from 0.2.x to a big version 1.0.x. Will the docker with containerd 1.0.x be compatible with current dockerd?

I think there is lots of changes between two different versions, such as image and namespace or something else.

Contributor

allencloud commented Sep 22, 2017

Hi, @mlaventure Thanks for your work very much.
While here I have a question for the change of containerd's version. After all, it is from 0.2.x to a big version 1.0.x. Will the docker with containerd 1.0.x be compatible with current dockerd?

I think there is lots of changes between two different versions, such as image and namespace or something else.

@mlaventure

This comment has been minimized.

Show comment
Hide comment
@mlaventure

mlaventure Sep 22, 2017

Contributor

@allencloud those changes shouldn't affect users, they're internal changes. Only the person who used to bypass docker to talk directly to containerd would be affected, but that was never a case supported by docker itself.

Also, only the runtime gets updated with this PR, graphdriver will get there a wee later

Contributor

mlaventure commented Sep 22, 2017

@allencloud those changes shouldn't affect users, they're internal changes. Only the person who used to bypass docker to talk directly to containerd would be affected, but that was never a case supported by docker itself.

Also, only the runtime gets updated with this PR, graphdriver will get there a wee later

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 20, 2017

Contributor

@AkihiroSuda Would like to get it in ASAP (i.e. today). Since this is only using the runtime portion the risk is low except for the incompatibility with the previous version.

Contributor

cpuguy83 commented Oct 20, 2017

@AkihiroSuda Would like to get it in ASAP (i.e. today). Since this is only using the runtime portion the risk is low except for the incompatibility with the previous version.

@cpuguy83

I'm ok that an upgrade breaks people who have live-restore on the previous version, while this has generally worked in the past it really should never be a guarantee.... people consuming moby will need to make sure to handle this properly.

mlaventure added some commits Sep 22, 2017

Update libcontainerd to use containerd 1.0
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Fix tests creating zombie processes
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
@yongtang

This comment has been minimized.

Show comment
Hide comment
@yongtang

yongtang Oct 20, 2017

Member

It seems that there are enough LGTMs. Move it to status/4-merge. Let's see if all Jenkins builds pass.

Member

yongtang commented Oct 20, 2017

It seems that there are enough LGTMs. Move it to status/4-merge. Let's see if all Jenkins builds pass.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83
Contributor

cpuguy83 commented Oct 20, 2017

@allencloud

This comment has been minimized.

Show comment
Hide comment
@allencloud

allencloud Oct 21, 2017

Contributor

I think there are several breaking back compatibility.
For example, containerd 2.3.x allows user to choose one runtime when running, such as runc, runv and so on.
But containerd 1.0.0 does not allow this.
Do we need to record this kind of thing is some documentation?

Contributor

allencloud commented Oct 21, 2017

I think there are several breaking back compatibility.
For example, containerd 2.3.x allows user to choose one runtime when running, such as runc, runv and so on.
But containerd 1.0.0 does not allow this.
Do we need to record this kind of thing is some documentation?

@mlaventure

This comment has been minimized.

Show comment
Hide comment
@mlaventure

mlaventure Oct 21, 2017

Contributor

@allencloud changing the runtime binary is still supported by containerd 1.0

You will notice that I did not remove any test, and setting the runtime binary is part of them. I've replicated all of the previous features, there should be no regressions normally. If there is, it means we're lacking tests for it.

Contributor

mlaventure commented Oct 21, 2017

@allencloud changing the runtime binary is still supported by containerd 1.0

You will notice that I did not remove any test, and setting the runtime binary is part of them. I've replicated all of the previous features, there should be no regressions normally. If there is, it means we're lacking tests for it.

@cpuguy83 cpuguy83 merged commit 4025407 into moby:master Oct 23, 2017

6 checks passed

dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 37459 has succeeded
Details
janky Jenkins build Docker-PRs 46150 has succeeded
Details
powerpc Jenkins build Docker-PRs-powerpc 6542 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 17731 has succeeded
Details
z Jenkins build Docker-PRs-s390x 6344 has succeeded
Details
@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael Oct 23, 2017

Contributor

LGTM

Contributor

crosbymichael commented Oct 23, 2017

LGTM

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Oct 24, 2017

Member

Wait; why did Janky show it passed?

16:31:46 Step 1 : FROM golang:1.8.4-alpine3.6 as builder
16:31:46 Error parsing reference: "golang:1.8.4-alpine3.6 as builder" is not a valid repository/tag
16:31:46 Set build name.
16:31:46 New build name is '#34895'
16:31:46 Variable with name 'BUILD_
Member

thaJeztah commented Oct 24, 2017

Wait; why did Janky show it passed?

16:31:46 Step 1 : FROM golang:1.8.4-alpine3.6 as builder
16:31:46 Error parsing reference: "golang:1.8.4-alpine3.6 as builder" is not a valid repository/tag
16:31:46 Set build name.
16:31:46 New build name is '#34895'
16:31:46 Variable with name 'BUILD_
@tophj-ibm

This comment has been minimized.

Show comment
Hide comment
@tophj-ibm

tophj-ibm Oct 24, 2017

Contributor

@thaJeztah from the jenkins-job config, not sure why this is the case:
docker build --build-arg DOCKER_GITCOMMIT=$GITCOMMIT -t docker-e2e-test:$GITCOMMIT -f Dockerfile.e2e . || true
https://jenkins.dockerproject.org/job/Docker-PRs/configure

Contributor

tophj-ibm commented Oct 24, 2017

@thaJeztah from the jenkins-job config, not sure why this is the case:
docker build --build-arg DOCKER_GITCOMMIT=$GITCOMMIT -t docker-e2e-test:$GITCOMMIT -f Dockerfile.e2e . || true
https://jenkins.dockerproject.org/job/Docker-PRs/configure

@dnephin

This comment has been minimized.

Show comment
Hide comment
@dnephin

dnephin Oct 24, 2017

Member

The Dockerfile.e2e is an image that is used to test docker-ce/docker-ee in other builds. We'd like to test it here as an artifact of the `moby/moby build.

|| true was added because this image uses multi-stage builds, and not all jenkins node run a Docker version that supports multi-stage builds, which is the error you pasted.

Member

dnephin commented Oct 24, 2017

The Dockerfile.e2e is an image that is used to test docker-ce/docker-ee in other builds. We'd like to test it here as an artifact of the `moby/moby build.

|| true was added because this image uses multi-stage builds, and not all jenkins node run a Docker version that supports multi-stage builds, which is the error you pasted.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Oct 24, 2017

Member

Oh, possibly because those tests are only used in the internal e2e suite, yes. I got confused, was looking why the vendor check didn't fail on this PR (https://github.com/moby/moby/pull/35283/files#r146650223)

edit: see @dnephin's comment, our comments just crossed

Member

thaJeztah commented Oct 24, 2017

Oh, possibly because those tests are only used in the internal e2e suite, yes. I got confused, was looking why the vendor check didn't fail on this PR (https://github.com/moby/moby/pull/35283/files#r146650223)

edit: see @dnephin's comment, our comments just crossed

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 20, 2017

Member

This change actually masks that the test is defunct; 17 container * 7 events = 119, so the limit of 256 events is never reached.

Member

thaJeztah commented on integration-cli/docker_cli_events_test.go in ddae20c Dec 20, 2017

This change actually masks that the test is defunct; 17 container * 7 events = 119, so the limit of 256 events is never reached.

This comment has been minimized.

Show comment
Hide comment
@mlaventure

mlaventure Dec 20, 2017

Contributor

I see that the string is incorrect, not sure what you mean by "defunct"?

Contributor

mlaventure replied Dec 20, 2017

I see that the string is incorrect, not sure what you mean by "defunct"?

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 20, 2017

Member

@mlaventure The test tests that the number of events is limited to 256 events, but we only check if 119 events are fired, so basically this is now only testing that we receive all the events that were triggered.

This test was quite problematic anyway, and turns out it was already tested elsewhere, so opened a PR to remove it (see #35844 for a fun walk through history)

Member

thaJeztah replied Dec 20, 2017

@mlaventure The test tests that the number of events is limited to 256 events, but we only check if 119 events are fired, so basically this is now only testing that we receive all the events that were triggered.

This test was quite problematic anyway, and turns out it was already tested elsewhere, so opened a PR to remove it (see #35844 for a fun walk through history)

This comment has been minimized.

Show comment
Hide comment
@mlaventure

mlaventure Dec 20, 2017

Contributor

The test tests that the number of events is equal to numContainers*eventPerContainer I had to fix the test because the number of events changed with 1.0, I just forgot to update the error message :). Is the test still flaky? I never got it to fail after I updated it.

Contributor

mlaventure replied Dec 20, 2017

The test tests that the number of events is equal to numContainers*eventPerContainer I had to fix the test because the number of events changed with 1.0, I just forgot to update the error message :). Is the test still flaky? I never got it to fail after I updated it.

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 20, 2017

Member

No, the test should be testing that events are limited to 256; https://github.com/moby/moby/pull/6918/files

Member

thaJeztah replied Dec 20, 2017

No, the test should be testing that events are limited to 256; https://github.com/moby/moby/pull/6918/files

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 20, 2017

Member

(that's the original PR, at which time it was 64)

Member

thaJeztah replied Dec 20, 2017

(that's the original PR, at which time it was 64)

This comment has been minimized.

Show comment
Hide comment
@mlaventure

mlaventure Dec 20, 2017

Contributor

Well, in that case it should have been checking for LessOrEqual. Now it tests that we have exactly the right number of events, but since it is apparently tested already somewhere, RIP :)

Contributor

mlaventure replied Dec 20, 2017

Well, in that case it should have been checking for LessOrEqual. Now it tests that we have exactly the right number of events, but since it is apparently tested already somewhere, RIP :)

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Dec 20, 2017

Member

Yes, that test was a big PITA for a long time; I looked into that test a while back to look what it was actually doing, then found the history (but never got round to actually removing it)

Member

thaJeztah replied Dec 20, 2017

Yes, that test was a big PITA for a long time; I looked into that test a while back to look what it was actually doing, then found the history (but never got round to actually removing it)

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