LGTM

maybe it should also be prevented w/ --net=container

@proppy I think maybe so because I was just trying to do links with --net:container and at first couldn't figure out why docker kept saying "Cannot start container .. (exit status 2)". I guess considering what linking does it makes sense. I am guessing I can put the --link on the other container my network is coming from.

Hello. I've just encountered a special corner-case, whereby both --net=host and --link is needed together in the same container. It's a special one,

I've been able package @jpetazzo's pipework tool inside a docker container. Now it should be possible to configure pipework inside fig or crane .yml. However with these tools, it seems to be entirely necessary to use the --link feature on the pipework container. To ensure that it is pipework which is run after all of the other app containers have been started. That is required make sure that when pipework is run, it can enter any of those running service containers and create the additional pipework network interfaces inside of them. I'm not aware of any other mechanism for those 2 tools (crane and fig) that can ensure the startup order. Please correct me if I'm wrong about that.

Anyway. For pipework (inside it's own privileged container) to actually create the other half of the new macvlan circuits on the host side, well that requires pipework to see the host interfaces from inside it's container. So the --net=host option is also required for the pipework container at the same time… have indeed verified that is the case.

What I'm not understanding here is why this particular combination has been disallowed. Surely if the linked containers aren't also --net=host (only the master container) then there should be no ports / networking conflict ? Am I misunderstanding something?

Not sure what to do now as this seems to be the last obstacle to get pipework running in a crane (and of course fig too). Is there any way to get around / override this kind of safety feature in docker, assuming that it is not down to a fundamental technical limitation? Or else can I set --net=none on the master container, and re-add the host's networking stack manually inside the pipework container with a bunch of ip netns / similar commands? Since Pipework already requires full privileges to do its thing.

@jpetazzo If we solve these obstacles, should I eventually upload / publish this new pipework docker image simply as 'dreamcat4/pipework', or else would you suggest some slightly different name?

@dreamcat4 This isn't about port conflicts, this is about the fact that there were a lot of problems around this and supporting something like this takes a lot of work. The edge cases might never be figured out and the amount of effort required to get even to that point isn't negligible.

Ok @unclejack thanks for the heads up. Then it sounds easier to solve my problem in some different way, which will avoid the need to use Docker links.

For example if I can instead keep my container constantly running in the background. Then to be notified whenever a new container comes up / is started. Then it will be possible to have my service loop notice and launch the pipework script jump in at that point in time… Don't seem to have any better ideas ATM.