- To also return the configured exposed ports, besides the
port bindings; as now libnetwork/endpoint.go endpoint setters
separate the exposed ports and port binding configs.
Docker daemon will take care of aggregating the two sources
for presentation.
Signed-off-by: Alessandro Boch <aboch@docker.com>
- Also unexporting configuration structures in bridge
- Changes in dnet/network.go to set bridge name = network name
Signed-off-by: Alessandro Boch <aboch@docker.com>
Currently the driver api allows the driver to specify the
full interface name for the interface inside the container.
This is not appropriate since the driver does not have the full
view of the sandbox to correcly allocate an unambiguous interface
name. Instead with this PR the driver will be allowed to specify
a prefix for the name and libnetwork and sandbox layers will
disambiguate it with an appropriate suffix.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
In essense, this just involves marshalling structs back and forth to a
remote process, via the plugin client. There are a couple of types
that don't JSONify well, notably `net.IPNet`, so there is some
translation to be done.
To conform to the driverapi interface, we must give the list of
endpoint interfaces to the remote process, and let it puzzle out what
it's supposed to do; including the possibility of returning an error.
The constraints on EndpointInfo are enforced by the remote driver
implementation; namely:
* It can't be nil
* If it's got non-empty Interfaces(), the remote process can't put
more in
In the latter case, or if we fail to add an interface for some
(future) reason, we try to roll the endpoint creation back. Likewise
for join -- if we fail to set the fields of the JoinInfo, we roll the
join back by leaving.
Signed-off-by: Michael Bridgen <mikeb@squaremobius.net>
- Package types to define the interfaces libnetwork errors
may implement, so that caller can categorize them.
Signed-off-by: Alessandro Boch <aboch@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>
This commit brings in Remote driver integrated with the newly introduced
Plugin framework as a Docker Package.
The Plugin framework is designed as a Package and has no runtime
dependancy on Docker platform. It stands on its own and is a good
candidate for getting the remote drivers hooked to libnetwork
Signed-off-by: Madhu Venugopal <madhu@docker.com>
If the bridge exists and it exists with a different link local ip address
than fe80::1/64 then we waifl to accept that as a valid configuration without
trying to add the default link local ip address. With this fix we always try
to add the default link local address if it doesn't exist.
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>
This commits brings in a functionality for remote drivers to register
with LibNetwork. The Built-In remote driver is responsible for the
actual "remote" plugin to be made available.
Having such a mechanism makes libnetwork core not dependent on any
external plugin mechanism and also the Libnetwork NB apis are free of
Driver interface.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
using a len(net.IP) to check for ipv4 or ipv6 is a bad idea.
And that was exactly done in NetworkOverlaps() function with the
assumption that any ipv4 net.IP will be of 4 bytes. Golang Net package
makes no such assumptions.
This assumption actually broke a particular use-case where the
NetworkOverlaps fails to identify a genuine overlap and that causes
datapath issues.
With this fix, we explicitely check for v4 or v6
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Jana Radhakrishnan