When you start a container after some other container has already
been started in the same network, the current container will have
an fdb which points to a wrong vtep to reach the already started
container. This makes the network connectivity to not work. The root
cause of the issue is because of golang does variable capture by
reference in closures and so we cannot use the return values from
range iterators directly. It needs to be copied to a locally scoped
variable and then use that copy as a capture variable in the closure.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
libnetwork.New() should return a controller and an error. The
example in README.md ignore the error now, which will let the
codes can not be compiled by Go.
When fixed-cidrv6 is used, the allocation and release must happen from
the appropriate network. Allocation is done properly in createendpoint,
but the DeleteEndpoint wasnt taking care of this case.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
When bit sequence is trying to get key/value from the
data store it should always unmarshall the json data
before using it, as the data is JSON marshalled before
storing it in the data store.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- We must ignore key not found error when querying
datastore for initial state.
- Regression introduced by 04bd8f67ad
Signed-off-by: Alessandro Boch <aboch@docker.com>
For the moment in 1.7.1 since we provide a resolv.conf set api
to the driver honor that so that for host driver we can use the
the host's /etc/resolv.conf file as is rather than putting the
contents through a filtering logic.
It should be noted that the driver side capability to set the
resolv.conf file is most likely going to go away in the future
but this should be fine for 1.7.1
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
In preparation for the new update of vishvananda/netlink package
we need to bringup the host veth interface manually.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Some parts of the bridge driver code needs to use a different kernel
api or use the already existing apis in slightly different ways to
make the bridge driver work in RHEL/Centos 6.6. This PR provides
those fixes.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
The netlink way of creating bridge has problems in older
kernels like the one used on RHEL 6 (which is a supported
one). So trying to use ioctl method to create bridge
so that it works on any version.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- When invoked from docker, endpoint.Statistics() returns
the statistics of the host's interfaces.
Issue is tracked down to ioutil.ReadFile(). For some
reason even if invoked from inside the sandbox netns,
it ends up reading the stats file from the default netns,
when invoked from docker.
If same operation is run from inside a dedicated binary,
it works as expected.
- Replacing it with exec.Command("cat", <file>) solves the issue
Signed-off-by: Alessandro Boch <aboch@docker.com>
In that commit, AtomicPutCreate takes previous = nil to Atomically create keys
that don't exist. We need a create operation that is atomic to prevent races
between multiple libnetworks creating the same object.
Previously, we just created new KVs with an index of 0 and wrote them to the
datastore. Consul accepts this behaviour and interprets index of 0 as
non-existing, but other data backends do no.
- Add Exists() to the KV interface. SetIndex() should also modify a KV so
that it exists.
- Call SetIndex() from within the GetObject() method on DataStore interface.
- This ensures objects have the updated values for exists and index.
- Add SetValue() to the KV interface. This allows implementers to define
their own method to marshall and unmarshall (as bitseq and allocator have).
- Update existing users of the DataStore (endpoint, network, bitseq,
allocator, ov_network) to new interfaces.
- Fix UTs.
There is no need to update the /etc/hosts files
of containers for endpoints which are created/deleted
in a network whose interface list is empty
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
