Since libnetwork is going to provide createNetwork
notifications only once when the network is created
bridge network needs to save it's network state in
persistent store so that it becomes available even
after restart.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
- Set bridge ipv4 address when bridge is present
- IPv6 changes for bridge
- Convert unit tests to the new model
Signed-off-by: Alessandro Boch <aboch@docker.com>
- Renamed netlabel prefixes to accomodate both global
and local store configs.
- Added a `private` marker.
- Skipping the data store configs for remote driver
so that external plugins don't get it as there is
no secure and sane way to coordinate providing
data store access to external plugins.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
There were some unconditional debug logging in serf.
Removed them and made then go through logrus writers
based on what error level the log string contains.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Always on watching of networks and endpoints can
affect scalability of the cluster beyond a few nodes.
Remove pro active watching and watch only the objects
you are interested in.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
With the new Discovery model, join can happen even before serf is
initliazed. It could also happen due to misconfiguration of
--cluster-advertise. The local endpoint join must succeed and later when
the serf initializes and joins the cluster, it will push the local db to
the cluster.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
With the recently introduced docker discovery, the self node discovery
notification can reach the overlay driver after the remote node
discovery notification. In scenarios such as 2 node setup, it seems more
likely. In those scenarios, the serfJoin is not triggered and hence the
neighborship is not formed between the 2 nodes.
The fix is to retain the knowledge of the neighbor and reuse it
immediately after the serfInit is done. Since we do the serfJoin just
once, there is no harm in changing the neighIP to a new value even if it
is not used.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
* integrated hostdiscovery package with the new Docker Discovery
* Integrated hostdiscovery package with libnetwork core
* removed libnetwork_discovery tag
* Introduced driver apis for discovery events
* moved overlay driver to make use of the discovery events
* Using Docker Discovery service.
* Changed integration-tests to make use of the new discovery
Signed-off-by: Madhu Venugopal <madhu@docker.com>
- DisableBridgeCreation is misleading. change it to DefaultBridge
- Dont fail the init if localstore cannot be initialized
- added a convenience function to get endpoint for a container
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Ideally, both overlay and libnetwork core must be changed to support
kv-store connection retry. But this is a stop-gap measure to unblock the
discovery related PRs.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Replaced it with DisableBridgeCreation and it can be used ONLY in
a special case for docker0 bridge from docker, instead of calling it
from all other case.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
1. Don't save localscope endpoints to localstore for now.
2. Add common function updateToStore/deleteFromStore to store KVObjects.
3. Merge `getNetworksFromGlobalStore` and `getNetworksFromLocalStore`
4. Add `n.isGlobalScoped` before `n.watchEndpoints` in `addNetwork`
5. Fix integration-tests
6. Fix test failure in drivers/remote/driver_test.go
7. Restore network to store if deleteNework failed
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>
There are multiple goals of introducing test driver plugin
- Need a driver which can be configured to simulate
different driver behaviors
- For pure libnetwork multi-host integration testing
a test driver configured for global scope can be used
without trying to use a real driver like overlay
which comes with it's own dependencies which can't
be satisfied all enviroments(I am looking at you
circleci)
This PR also makes all test cases that we have so far to be run
in circleci without any skipping needed.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Add one capability negotiation interaction after plugin handshake, use
this to determine plugin's capability instead of default "global" scope.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Currently the endpoint data model consists of multiple
interfaces per-endpoint. This seems to be an overkill
since there is no real use case for it. Removing it
to remove unnecessary complexity from the code.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
There were two pending PRs with package level
changes but no source level conflicts. This got
merged because git cannot detect this.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
This way we won't vendor test related functions in docker anymore.
It also moves netns related functions to a new ns package to be able to
call the ns init function in tests. I think this also helps with the
overall package isolation.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Bridge driver panics in `CreateNetwork` if called without
a prior `Config` call. This causes issues in dnet which
tries to create network using default driver configuration.
It should be valid to call `CreateNetwork` without a prior
`Config` call in which case we need to assume default driver
config.
Fixed this by properly initializing the driver config pointer.
Also introduced a `configured` bool to make sure that still
`Config` is called exactly once for the instance of the bridge
driver.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Make sure to always explicitly set namespace for all
kernel bound network operations irrespective of whether
the operation is performed in init namespace or a user
defined namespace. This already happens for user defined
netns. But doesn't happen for initial netns that libnetwork
runs in.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Alessandro Boch