Commit Graph

4 Commits

Author SHA1 Message Date
Madhu Venugopal 9054ac2b48 Provide a way for libnetwork to make use of Agent mode functionalities
Signed-off-by: Madhu Venugopal <madhu@docker.com>
2016-06-05 18:41:21 -07:00
Madhu Venugopal 0066225da5 Integration with Docker Discovery
* 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>
2015-10-01 12:32:55 -07:00
Madhu Venugopal 8b59f48537 Reading the top level element (network) from datastore on init
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>
2015-06-18 08:35:46 -07:00
Madhu Venugopal 03504cab65 Few changes to the UI and API implementation
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>
2015-06-14 21:57:18 -07:00