Currently the libnetwork function `NewNetwork` does not allow
caller to pass a network ID and it is always generated internally.
This is sufficient for engine use. But it doesn't satisfy the needs
of libnetwork being used as an independent library in programs other
than the engine. This enhancement is one of the many needed to
facilitate a generic libnetwork.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- runs to completion without error
- demonstrates info available when using bridge network driver
Closes#837
Signed-off-by: Gabe Rosenhouse <grosenhouse@pivotal.io>
Currently the driver configuration is pushed through a separate
api. This makes driver configuration possible at any arbitrary
time. This unncessarily complicates the driver implementation.
More importantly the driver does not get access to it's
configuration before it can do the handshake with libnetwork.
This make the internal drivers a little bit different to
external plugins which can get their configuration before the handshake
with libnetwork.
This PR attempts to fix that mismatch between internal drivers and
external plugins.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- Maps 1 to 1 with container's networking stack
- It holds container's specific nw options which
before were incorrectly owned by Endpoint.
- Sandbox creation no longer coupled with Endpoint Join,
sandbox and endpoint have now separate lifecycle.
- LeaveAll naturally replaced by Sandbox.Delete
- some pkg and file renaming in order to have clear
mapping between structure name and entity ("sandbox")
- Revisited hosts and resolv.conf handling
- Removed from JoinInfo interface capability of setting hosts and resolv.conf paths
- Changed etchosts.Build() to first write the search domains and then the nameservers
Signed-off-by: Alessandro Boch <aboch@docker.com>
The configuration format for docker runtime is based on daemon flags and
hence adjusting the libnetwork configuration to accomodate it by moving
the TOML based configuration to the dnet tool.
Also changed the controller configuration via options
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Now that Endpoint interface has the Info method there is no
need to return container data as a return value in the Join
method. Removed the return value and fixed all the callers.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
This is need to decouple types from netutils which has linux
dependencies. This way the client code which needs network types
can just pull in types package which makes client code platform
agnostic.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Refactored the driver api so that is aligns well with the design
of endpoint lifecycle becoming decoupled from the container lifecycle.
Introduced go interfaces to obtain address information during CreateEndpoint.
Go interfaces are also used to get data from driver during join.
This sort of deisgn hides the libnetwork specific type details from drivers.
Another adjustment is to provide a list of interfaces during CreateEndpoint. The
goal of this is many-fold:
* To indicate to the driver that IP address has been assigned by some other
entity (like a user wanting to use their own static IP for an endpoint/container)
and asking the driver to honor this. Driver may reject this configuration
and return an error but it may not try to allocate an IP address and override
the passed one.
* To indicate to the driver that IP address has already been allocated once
for this endpoint by an instance of the same driver in some docker host
in the cluster and this is merely a notification about that endpoint and the
allocated resources.
* In case the list of interfaces is empty the driver is required to allocate and
assign IP addresses for this endpoint.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
In the present code, each driver package provides a `New()` method
which constructs a driver of its type, which is then registered with
the controller.
However, this is not suitable for the `drivers/remote` package, since
it does not provide a (singleton) driver, but a mechanism for drivers
to be added dynamically. As a result, the implementation is oddly
dual-purpose, and a spurious `"remote"` driver is added to the
controller's list of available drivers.
Instead, it is better to provide the registration callback to each
package and let it register its own driver or drivers. That way, the
singleton driver packages can construct one and register it, and the
remote package can hook the callback up with whatever the dynamic
driver mechanism turns out to be.
NB there are some method signature changes; in particular to
controller.New, which can return an error if the built-in driver
packages fail to initialise.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
* 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>
- Removed sandbox key argument for CreateEndpoint.
- Refactored bridge driver code to remove sandbox key.
- Fixed bridge driver code for gaps in ipv6 behavior
observed during docker integration.
- Updated test code, readme code, README.md according
api change.
- Fixed some sandbox issues while testing docker ipv6
integration.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- 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 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>
