sandbox_externalkey.go: split for cross compilation by runcom · Pull Request #770 · moby/libnetwork

runcom · 2015-11-23T22:19:56Z

runc/libcontainer split the State struct into platform specific structs
in
opencontainers/runc@fe1cce6.
As a result, NamespacePaths isn't anymore in a global struct and
libnetwork is not cross-compiling in Docker (specifically on Windows) because
sandbox_externalkey.go is using NamespacePaths.
This patch splits sandbox_externalkey.go into platform specific
files and moves common things to a generic sandbox_externalkey.go.

related to moby/moby#18106

Signed-off-by: Antonio Murdaca runcom@redhat.com

runcom · 2015-11-24T01:05:46Z

ping @mavenugo @mrjana @aboch (sorry for the noise)

mrjana · 2015-11-24T01:12:22Z

sandbox_externalkey_unsupported.go

Shouldn't all these return an appropriate error? We specifically have an error interface defined for this purpose.

https://github.com/docker/libnetwork/blob/master/types/types.go#L480

I'll update, wasn't aware of that kind of error, thanks

@mrjana there's a problem with https://github.com/docker/libnetwork/blob/master/controller.go#L200 because if we now return an error something can break if some Docker code path come across this and controller.go seems pretty platform agnostic, WDYT?

I've made what's used outside those files to return nil as a no-op and return a ErrNotImplemented otherwise, I hope it makes sense now

I also think only SetExternalKey should return that kind of error because it's part of the API, the other functions can basically return nil

mrjana · 2015-11-24T21:53:30Z

LGTM

mavenugo · 2015-11-25T02:23:55Z

@runcom this fix seems to have made the externalkey support specific to linux.
Are we sure this doesn't have a negative impact on FreeBSD/ARM, etc ?
Can you please confirm ?

jessfraz · 2015-11-25T20:05:39Z

sandbox_externalkey_unix.go

maybe !windows instead?

runcom · 2015-11-25T21:42:18Z

@jfrazelle updated as per your comment

jessfraz · 2015-11-25T22:00:29Z

\o/ all up to @mavenugo

mavenugo · 2015-11-25T23:07:34Z

Sorry about the delay.
With the changes to !windows shouldn't we just add a _windows.go file and not do unsupported? Even if we do _unsupported.go, isn't it appropriate to include just the Windows target ?

runcom · 2015-11-25T23:14:45Z

make sense, most docker code is the way you said @mavenugo (i.e. https://github.com/docker/docker/blob/master/daemon/container_windows.go and https://github.com/docker/docker/blob/master/daemon/container_unix.go)
I'll update the PR (another example is https://github.com/docker/docker/tree/master/pkg/idtools)

runc/libcontainer split the `State` struct into platform specific structs in opencontainers/runc@fe1cce6. As a result, `NamespacePaths` isn't anymore in a global struct and libnetwork is not cross-compiling in Docker (specifically on Windows) because `sandbox_externalkey.go` is using `NamespacePaths`. This patch splits `sandbox_externalkey.go` into platform specific files and moves common things to a generic `sandbox_externalkey.go`. Signed-off-by: Antonio Murdaca <runcom@redhat.com>

runcom · 2015-11-25T23:30:25Z

green again :) I'm testing with Docker&libcontainer in make cross

mavenugo · 2015-11-25T23:39:41Z

Thanks. LGTM

aboch · 2015-11-25T23:40:09Z

LGTM

sandbox_externalkey.go: split for cross compilation

runcom · 2015-11-25T23:40:23Z

Thanks all!

runcom mentioned this pull request Nov 23, 2015

vendor: bump libcontainer and its deps moby/moby#18106

Merged

runcom force-pushed the fix-cross-compile branch 2 times, most recently from dd4b60b to 2ac51e8 Compare November 23, 2015 23:31

mrjana reviewed Nov 24, 2015
View reviewed changes

runcom force-pushed the fix-cross-compile branch 3 times, most recently from 03f1c3c to 41eff70 Compare November 24, 2015 01:23

dave-tucker mentioned this pull request Nov 24, 2015

Multi-Arch Support #186

Merged

jessfraz mentioned this pull request Nov 24, 2015

Phase 1: Initial seccomp support moby/moby#17989

Merged

mavenugo mentioned this pull request Nov 25, 2015

Allow libnetwork to compile on freebsd #772

Merged

runcom force-pushed the fix-cross-compile branch 3 times, most recently from dfda5e0 to 3b00cdf Compare November 25, 2015 13:42

jessfraz reviewed Nov 25, 2015
View reviewed changes

runcom force-pushed the fix-cross-compile branch from 3b00cdf to 6df87a4 Compare November 25, 2015 21:42

runcom force-pushed the fix-cross-compile branch from 6df87a4 to 1985db8 Compare November 25, 2015 21:43

runcom force-pushed the fix-cross-compile branch from 1985db8 to 806157b Compare November 25, 2015 23:18

aboch added a commit that referenced this pull request Nov 25, 2015

Merge pull request #770 from runcom/fix-cross-compile

04cc1fa

sandbox_externalkey.go: split for cross compilation

aboch merged commit 04cc1fa into moby:master Nov 25, 2015

runcom deleted the fix-cross-compile branch November 25, 2015 23:40

Conversation

runcom commented Nov 23, 2015

Uh oh!

runcom commented Nov 24, 2015

Uh oh!

mrjana Nov 24, 2015

Choose a reason for hiding this comment

Uh oh!

runcom Nov 24, 2015

Choose a reason for hiding this comment

Uh oh!

runcom Nov 24, 2015

Choose a reason for hiding this comment

Uh oh!

runcom Nov 24, 2015

Choose a reason for hiding this comment

Uh oh!

runcom Nov 24, 2015

Choose a reason for hiding this comment

Uh oh!

mrjana commented Nov 24, 2015

Uh oh!

mavenugo commented Nov 25, 2015

Uh oh!

jessfraz Nov 25, 2015

Choose a reason for hiding this comment

Uh oh!

runcom Nov 25, 2015

Choose a reason for hiding this comment

Uh oh!

runcom commented Nov 25, 2015

Uh oh!

jessfraz commented Nov 25, 2015

Uh oh!

mavenugo commented Nov 25, 2015

Uh oh!

runcom commented Nov 25, 2015

Uh oh!

runcom commented Nov 25, 2015

Uh oh!

mavenugo commented Nov 25, 2015

Uh oh!

aboch commented Nov 25, 2015

Uh oh!

runcom commented Nov 25, 2015

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants