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

Update moby to containerd and runc 1.0 final rc #33007

Merged
merged 1 commit into from May 8, 2017

Conversation

Projects
None yet
9 participants
@crosbymichael
Contributor

crosbymichael commented May 3, 2017

Getting this up for review, I'll have to change the repo paths one last time before we can merge but CI takes so long to run I wanted to open this now.

This is the last rc for the runtime spec and runc before a 1.0 release.

@vieux

This comment has been minimized.

Show comment
Hide comment
@vieux

vieux May 4, 2017

Collaborator

@crosbymichael panic in the unit tests

Collaborator

vieux commented May 4, 2017

@crosbymichael panic in the unit tests

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 4, 2017

Contributor

@LK4D4 do you know why vndr is freaking out about my dep?

it was saying

18:36:29 2017/05/02 18:36:30 WARNING: packages 'github.com/opencontainers/selinux, github.com/opencontainers/selinux' has same root import github.com/opencontainers/selinux
18:36:29 2017/05/02 18:36:30 WARNING: suggested vendor.conf is written to vendor.conf.tmp, use diff and common sense before using it
18:36:29 2017/05/02 18:36:30 There were some validation errors
Contributor

crosbymichael commented May 4, 2017

@LK4D4 do you know why vndr is freaking out about my dep?

it was saying

18:36:29 2017/05/02 18:36:30 WARNING: packages 'github.com/opencontainers/selinux, github.com/opencontainers/selinux' has same root import github.com/opencontainers/selinux
18:36:29 2017/05/02 18:36:30 WARNING: suggested vendor.conf is written to vendor.conf.tmp, use diff and common sense before using it
18:36:29 2017/05/02 18:36:30 There were some validation errors
@@ -12,6 +12,25 @@ func iPtr(i int64) *int64 { return &i }
func u32Ptr(i int64) *uint32 { u := uint32(i); return &u }

This comment has been minimized.

@tonistiigi

tonistiigi May 4, 2017

Member

sPtr should be unused now

@tonistiigi

tonistiigi May 4, 2017

Member

sPtr should be unused now

This comment has been minimized.

@crosbymichael

crosbymichael May 5, 2017

Contributor

done

@crosbymichael

crosbymichael May 5, 2017

Contributor

done

Show outdated Hide outdated integration-cli/docker_cli_service_logs_test.go
@vieux

This comment has been minimized.

Show comment
Hide comment
@vieux

vieux May 5, 2017

Collaborator

@crosbymichael can you rebase ?

github.com/opencontainers/selinux ba1aefe8057f1d0cfb8e88d0ec1dc85925ef987d is already in master (last line of the vendor.conf)

That's why you end up with selinux errors with vndr.

Collaborator

vieux commented May 5, 2017

@crosbymichael can you rebase ?

github.com/opencontainers/selinux ba1aefe8057f1d0cfb8e88d0ec1dc85925ef987d is already in master (last line of the vendor.conf)

That's why you end up with selinux errors with vndr.

@thaJeztah thaJeztah added this to the 17.06.0 milestone May 5, 2017

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 5, 2017

Contributor

@vieux thanks

Contributor

crosbymichael commented May 5, 2017

@vieux thanks

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 5, 2017

Contributor

I'm having to update and sync the deps with runc because some of them are out of date and causing the validation to fail. The others will be a bump for docker's versions where runc depends on a newer version.

Contributor

crosbymichael commented May 5, 2017

I'm having to update and sync the deps with runc because some of them are out of date and causing the validation to fail. The others will be a bump for docker's versions where runc depends on a newer version.

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 5, 2017

Contributor

Can we turn off this new vendor comparison because runc is a binary dep I don't know why its diffing the vendor files.

Contributor

crosbymichael commented May 5, 2017

Can we turn off this new vendor comparison because runc is a binary dep I don't know why its diffing the vendor files.

@vdemeester

This comment has been minimized.

Show comment
Hide comment
@vdemeester

vdemeester May 5, 2017

Member

@crosbymichael as long as vendor.conf or vendor/* files are changed, the vendor check is run

16:22:02 ?? vendor/github.com/opencontainers/runc/vendor.conf

This file seems to be missing in the commit but is while using vndr.

Member

vdemeester commented May 5, 2017

@crosbymichael as long as vendor.conf or vendor/* files are changed, the vendor check is run

16:22:02 ?? vendor/github.com/opencontainers/runc/vendor.conf

This file seems to be missing in the commit but is while using vndr.

@crosbymichael

This comment has been minimized.

Show comment
Hide comment
@crosbymichael

crosbymichael May 5, 2017

Contributor

@vdemeester its comparing things it shouldn't because runc has a vendor.conf that is not used here because its a binary dep and shouldn't matter.

Contributor

crosbymichael commented May 5, 2017

@vdemeester its comparing things it shouldn't because runc has a vendor.conf that is not used here because its a binary dep and shouldn't matter.

Update moby to runc and oci 1.0 runtime final rc
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 8, 2017

Member

All green now @tonistiigi @mlaventure PTAL!

Member

thaJeztah commented May 8, 2017

All green now @tonistiigi @mlaventure PTAL!

@@ -77,7 +77,7 @@ func getMemoryResources(config containertypes.Resources) *specs.Memory {
memory.Reservation = &reservation
}
if config.MemorySwap != 0 {
if config.MemorySwap > 0 {

This comment has been minimized.

@cpuguy83

cpuguy83 May 8, 2017

Contributor

This one has been tricky, IIRC.

Seems -1 (previously unlimited) and 0 (unset) are now treated the same.

@cpuguy83

cpuguy83 May 8, 2017

Contributor

This one has been tricky, IIRC.

Seems -1 (previously unlimited) and 0 (unset) are now treated the same.

This comment has been minimized.

@mlaventure

mlaventure May 8, 2017

Contributor

This routine seems to only be used when creating the container spec initially (not when updating), in which case it's correct. The default value for that limit being unlimited.

@mlaventure

mlaventure May 8, 2017

Contributor

This routine seems to only be used when creating the container spec initially (not when updating), in which case it's correct. The default value for that limit being unlimited.

@mlaventure

LGTM

(one small nit)

if config.CPUShares != 0 {
if config.CPUShares < 0 {
return nil, fmt.Errorf("shares: invalid argument")

This comment has been minimized.

@mlaventure

mlaventure May 8, 2017

Contributor

nit: cpu shares: ...

@mlaventure

mlaventure May 8, 2017

Contributor

nit: cpu shares: ...

@tonistiigi

This comment has been minimized.

Show comment
Hide comment
@tonistiigi

tonistiigi May 8, 2017

Member

LGTM

Member

tonistiigi commented May 8, 2017

LGTM

@mlaventure mlaventure merged commit 7238cca into moby:master May 8, 2017

7 checks passed

dco-signed All commits are signed
experimental Jenkins build Docker-PRs-experimental 33734 has succeeded
Details
janky Jenkins build Docker-PRs 42338 has succeeded
Details
powerpc Jenkins build Docker-PRs-powerpc 2663 has succeeded
Details
vendor Jenkins build Docker-PRs-vendor 3331 has succeeded
Details
windowsRS1 Jenkins build Docker-PRs-WoW-RS1 13565 has succeeded
Details
z Jenkins build Docker-PRs-s390x 2443 has succeeded
Details

@crosbymichael crosbymichael deleted the crosbymichael:containerd-rc5 branch May 8, 2017

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah May 8, 2017

Member

@mlaventure can you verify if #32667 and #32699 should be resolved by this?

Member

thaJeztah commented May 8, 2017

@mlaventure can you verify if #32667 and #32699 should be resolved by this?

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