Updated resolvconf and iptables packages based on upstream
changes which we need for libnetwork rebase. There were
docker engine changes based on this so we need this to
be integrated now.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
The libnetwork test does not need to run inside a namespace
when inside a container. This results in unpredictable behavior
when the sandbox code unlocks the go routine from the OS thread
while the test code still wants it locked in the OS thread. This
will result in unreachable interfaces when the go routine
migrates to a different OS thread.
Fixed by passing a special test flag which is only set to true
when the test is run inside a container.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
* Modified NB API with self referential var-aarg for future proofing the APIs
* Modified Driver API's option parameter to be a Map of interface{}
Signed-off-by: Madhu Venugopal <madhu@docker.com>
DESCRIPTION:
As part of bringing libnetwork bridge driver features
in parity with docker/daemon/network/driver/bridge
features (Issue #46), this commit addresses the
bridge.RequestPort() API.
Currenlty docker/api/server.go needs an hold of port
allocator in order to reserve a transport port which
will be used by the http server on the host machine,
so that portallocator does not give out that port when
queried by portmapper as part of network driver operations.
ISSUE:
Current implementation in docker is server.go directly
access portmapper and then portallocator from bridge pkg
calling bridge.RequestPort(). This also forces that function
to trigger portmapper initialization (in case bridge init()
was not executed yet), while portmapper life cycle should
only be controlled by bridge network driver.
We cannot mantain this behavior with libnetwrok as this
violates the modularization of networking code which
libnetwork is bringing in.
FIX:
Make portallocator a singleton, now both docker core and
portmapper code can initialize it and get the only one instance
(Change in docker core code will happen when docker code
will migrate to use libnetwork), given it is being used for
host specific needs.
NOTE:
Long term fix is having multiple portallocator instances (so
no more singleton) each capable to be in sync with OS regarding
current port allocation.
When this change comes, no change whould be required on portallocator'
clients side, changes will be confined to portallocator package.
Signed-off-by: Alessandro Boch <aboch@docker.com>
