If resolvConfPath is unavailable and if the internally generated .hash file
is still present, then updateDNS should not consider the presence of internally
generated .hash. Rather, it must handle it as a case of using this
resolvConfPath for the first time.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
When an update is done to the container resolv.conf file
and it was inheriting host entries, then we should not
re-read the host entries when the container leaves and
re-joins the endpoint.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- Defines and implement http handler for "/networks" URLs
- Addresses part of requirements tracked by Issue #5
Signed-off-by: Alessandro Boch <aboch@docker.com>
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>
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>
- Refactored the Join/Leave code so they are synchronized across multiple go-routines
- Added parallel test coverage to test mult-thread access to Join/Leave
- Updated sandbox code to revert back to caller namespace when removing interfaces
- Changed the netns path to /var/run/netns so the cleanup is simpler on machine
reboot scenario
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
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>
Madhu Venugopal