3 Commits
Author SHA1 Message Date
Madhu Venugopal 8d03e80f21 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 aeae6b501d 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 5fcef105bb 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