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>
Madhu Venugopal