Subscribe to docker stats and place some in the Container topology.

[tomwilkie]

Work towards #114

[tomwilkie]

Note this introduces a startup lag (as it connects all the stats go routines on the main thread). This should be moved off to a background thread (and parallelised?)

[peterbourgon]

There's a lot of manual mutex locking going on. Since you already have a goroutine handling Docker events, why not thread all user requests through it, too? Then you can eliminate all the locks.

[tomwilkie]

Yes the locking makes me nervous; going to an actor model seems appropriate here.

I was always considering having our own Container struct, and moving all the stats & updating stuff into that. Then docker mapper is responsible for creating / removing containers in response to events.

We should probably also break out the mapper & topology logic to be a client of this type.

[peterbourgon]

I've been reading this for awhile and am having trouble building and keeping a mental model of what's happening. There's a lot of action at a distance, mutating the DockerTagger struct in-place. The preponderance of mutex-locking is an artifact of that. I think it would benefit from a single loop() method handling user requests, events from the Docker daemon, and events from individual /container/foo/stats streams.

[tomwilkie]

@peterbourgon I didn't go full actor on this, but I've rationalised the flow and locking.

Let me know what you think. There is a lot of potential for refactoring here, but I'd prefer to save anything major for another PR.

[peterbourgon]

Much, much easier to understand. Thanks a bunch. LGTM.

[tomwilkie]

Going to hold off on this until post 0.3