* Thanks to the Default gateway service in libnetwork, we dont have to add
containers explicitly to secondary public network. This is handled
automatically regardless of the primary network driver.
* Fixed the URL convention for kv-store to be aligned with the upcoming
changes to discovery URL
* Also, in order to bring consistency between external and internal network
drivers, we moved the driver configs via controller Init.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 6db1592066da48cf9ac619cef7d8d7b3a39db518
Component: engine
This fixes a regression caused by PR #16538.
Signed-off-by: Darren Stahl <darst@microsoft.com>
Upstream-commit: 5aa7c2317a253d88023b6285e50cd660fa351d77
Component: engine
goroutine fairness is not guaranteed causing the hang with GCCGO (x86 GCCGO CI)
Upstream-commit: 7a1dbd17fcab5ca76547d9d77c864f972e2638d3
Component: engine
- Libnetwork brings in :
* Default Gateway as a service for network drivers
* Persistence for local scoped networks using libkv
* BATS based Multi-host Integration-test infra and end-to-end tests
* libnetwork fixes for zookeeper and etcd backend
- Libkv upgrade brings in :
* boltdb support for local kv persistence
* other general bug fixes
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 59a000ec7fc31ef4dedc526ef77e70af24f39585
Component: engine
- use existing exposed type
Signed-off-by: Morgan Bauer <mbauer@us.ibm.com>
Upstream-commit: 93bd57b0b21e1a802b80388c8fc034780e3200fc
Component: engine
Avoid creating a global context object that will be used while the daemon is running.
Not only this object won't ever be garbage collected, but it won't ever be used for anything else than creating other contexts in each request. I think it's a bad practive to have something like this sprawling aroud the code.
This change removes that global object and initializes a context in the cases we don't have already one, like shutting down the server.
This also removes a bunch of context arguments from functions that did nothing with it.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 27c76522dea91ec585f0b5f0ae1fec8c255b7b22
Component: engine
This PR adds a "request ID" to each event generated, the 'docker events'
stream now looks like this:
```
2015-09-10T15:02:50.000000000-07:00 [reqid: c01e3534ddca] de7c5d4ca927253cf4e978ee9c4545161e406e9b5a14617efb52c658b249174a: (from ubuntu) create
```
Note the `[reqID: c01e3534ddca]` part, that's new.
Each HTTP request will generate its own unique ID. So, if you do a
`docker build` you'll see a series of events all with the same reqID.
This allow for log processing tools to determine which events are all related
to the same http request.
I didn't propigate the context to all possible funcs in the daemon,
I decided to just do the ones that needed it in order to get the reqID
into the events. I'd like to have people review this direction first, and
if we're ok with it then I'll make sure we're consistent about when
we pass around the context - IOW, make sure that all funcs at the same level
have a context passed in even if they don't call the log funcs - this will
ensure we're consistent w/o passing it around for all calls unnecessarily.
ping @icecrime @calavera @crosbymichael
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 26b1064967d9fcefd4c35f60e96bf6d7c9a3b5f8
Component: engine
This fixes some tests that were failing on windows
Signed-off-by: Darren Stahl <darst@microsoft.com>
Upstream-commit: ca5cc770b9f0d473b285f55eb78d507a8669ee41
Component: engine
