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>
- Enhance dnet to use codegansta/cli as the frontend
- Add `container create/rm` commands only in dnet
- With the above dnet enhancements add more integration tests
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Currently libnetwork does not have any integration test infra
support to tests libnetwork code end2end purely as a black
box. This initial commit adds the infra support to enable
test cases for 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>
Currently we rely on watch to catchup after the init. But there could be
a small time window on which, we might end up in a race condition on
network creates. By reading and populating networks during init, we
avoid any such conditions, especially for default network handling.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
1. replaced --net option for service UI with SERVICE.[NETWORK] format
2. Making using of the default network/driver backend support
3. NetworkName and NetworkType from the UI/API can be empty string
and it will be replaced with DefaultNetwork and DefaultDriver
As per the design goals, we wanted to keep libnetwork core free of
handling defaults. Rather, the clients (docker & dnet) must handle the
defaultness of these entities.
Also, since there is no API to get these Default values from the
backend, UI will not handle the default values either. Hence, this falls
under the responsibility of the API layer to handle this specific case.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
The configuration format for docker runtime is based on daemon flags and
hence adjusting the libnetwork configuration to accomodate it by moving
the TOML based configuration to the dnet tool.
Also changed the controller configuration via options
Signed-off-by: Madhu Venugopal <madhu@docker.com>
* Removed network from being marshalled (it is part of the key anyways)
* Reworked the watch function to handle container-id on endpoints
* Included ContainerInfo to be marshalled which needs to be synchronized
* Resolved multiple race issues by introducing data locks
Signed-off-by: Madhu Venugopal <madhu@docker.com>
In prep for the UI/API updates on Docker to integrate the network and
endpoints, this PR removes the experimental tag from dnet and moving it
to docker UI and API and wrap the top-level "network" and "service"
under experimental.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
In one of the previous commit, we went to the extreme of supporting just
the /{version}/networks. Though that satisfied the requirements for UI
integration, it is not fully consistent with Docker APIs.
Docker API supports both /{version}/resource and /resource and hence we
must add the same support for networks resource.
Also fixed a silly bug in api.go
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>
- Fix POST to collection
- Only resource ID in URI, search by name as query parameter
- Fix URLs, consistency and restrict regex
Signed-off-by: Alessandro Boch <aboch@docker.com>
