The `iptables.Exists` function is wrong in two ways:
1. The iptables -C call doesn't add `-j DOCKER` and fails to match
2. The long path takes ordering into account in comparison and fails to match
This patch fixes issue 1 by including `-j DOCKER` in the check.
Signed-off-by: Arnaud Porterie <arnaud.porterie@docker.com>
* When userland-proxy is disabled, enable hairpin mode on the host-side of the veth
* When userland-proxy is enabled, fix the iptable rules appropriately
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Calling GC() without ever creating a network namespace (sandbox on
Linux) will hang as the GC loop is not running (and therefore the
channel is not being listened to).
Tested via Docker that this corrects a daemon shutdown error if the
daemon is started and stopped without any containers or networks being
created while the daemon is up.
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
Currently we craete container mac address completely
randomly. But we probably need to generate based on
IP so that the mac address stays the same for a given
IP.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Right now the namespace paths are cleaned up every
garbage collection period. But if the daemon is restarted
before all the namespace paths of removed containers are
garbage collected they will remain there forever. The fix
is to provide a GC() api so that garbage collection can be
triggered immediately.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Current version of netns used in libnetwork do not have requisite syscall
entry for PowerPC (ppc64le) arch. Consequently docker which uses libnetwork fails
to create any network enabled containers on Power systems.
This patch updates netns to latest commit 5478c060110032f972e86a1f844fdb9a2f008f2c
to add ppc64le syscall entry.
Signed-off-by: Pradipta Kr. Banerjee <bpradip@in.ibm.com>
Do not have log output in packages that applications consume because the
output can mess with logs, stdout/stderr of applications and such and
there is nothing that the consumer can do about it other than change the
package that they are using.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Instead of sleeping reworked the code to use recurring ticks.
Also cleaned up unnecessary defers.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Loopback interface was s not brought up when wemoved
to clone method of creating namespace. e. Adding it.
Also taking care of PR R comments.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
This PR attempts to work around bugs present in kernel
version 3.18-4.0.1 relating to namespace creation
and destruction. This fix attempts to avoid certain
systemmcalls to not get in the kkernel bug path as well
as lazily garbage collecting the name paths when they are removed.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
In order to support the docker experimental feature build, moving the
service commands under experimental tag. Please refer to :
https://github.com/docker/docker/pull/13338/ for more information
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Though libnetwork api is supposed to handle the sub router, it is given
the entire URL to deal with. But the current api.go assumes the network/
to be in the root path.
We need this patch to make it work seamlessly with docker & dnet UI & API
Signed-off-by: Madhu Venugopal <madhu@docker.com>
It is needed in cases when mapped port is already bound, or another
application bind mapped port. All this will be undetected because we use
iptables and not net.Listen.
Signed-off-by: Alexander Morozov <lk4d4@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>
Jana Radhakrishnan