- To reflect work flow. NewDriver() => ConfigureDriver()
and no NetworkDriver returned.
libnetwork clients would refer to a driver/network type, then
internally controller will retrieve the correspondent driver
instance, but this is not a concern of the clients.
- Remove NetworkDriver interface
- Removed stale blank dependency on bridge in libnetwork_test.go
Signed-off-by: Alessandro Boch <aboch@docker.com>
- This address one of the requirements of Issue #78
- Bridge MTU will be enforced on the veth pair ifaces
for each endpoint being added to the network.
Signed-off-by: Alessandro Boch <aboch@docker.com>
- This addresses one requirement from Issue #79
- Defined EndpointConfiguration struct for bridge driver
which contains the user's preferred mac address for the
sanbox interface
Signed-off-by: Alessandro Boch <aboch@docker.com>
- Store *Interface on endpoint create
- Remove from bridgeEndpoint ip params now available in Interface
- On endpoint delete attempt a removal of veth plugged into bridge
- (tested disabling defer netutils.SetupTestNetNS(t)() in libnetwrok_test)
- Fix bridge to store endpoints per sandbox
- Fix bug in error.go which causes stack overflow
- Start bridge error string w/ lower case as per go convention
Signed-off-by: Alessandro Boch <aboch@docker.com>
- Move SanboxInfo and Interface structures in sandbox package
(changed it to Info as per golint)
- Move UUID to new internal pkg types
- Updated .gitignore to ignore IDE project files
Signed-off-by: Alessandro Boch <aboch@docker.com>
types, except the naked error returns which were just prefixing
strings to previously returned error strings.
Signed-off-by: Jana Radhakrishnan <mrjana@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>
- Added api enhancement to pass driver specific config
- Refactored simple bridge driver code for driver specific config
- Added an undocumented option to add non-default bridges without
manual pre-provisioning to help libnetwork testing
- Reenabled libnetwork test to do api testing
- Updated README.md
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- Modified Mac address generation to match current standard
- Moved GenerateRandomName from libcontainer and removed the dependancy.
- Reduced entropy loop to 3 attempts.
Signed-off-by: Brent Salisbury <brent.salisbury@docker.com>
