Push mini-reports when container states changes

[tomwilkie]

Fixes #629

[tomwilkie]

Right now, this change bypasses the 3s probe publish interval for docker container state changes, pushing a mini-report containing just the container node. As discussed, we're going to add a flag to reports (fastforward?) to indicate to the app that it should push a delta to the UI quickly too, eliminating another source of delay.

[tomwilkie]

Status: when a container state changes, a probe -> app mini report is pushed immediately; this causes an app -> ui topology push to also happen, and you get sub-second updated of the rendered graph (yay!)

Unfortunately, the details panel is on a 1 sec poll, driven by the UI, so is beyond scope for these changes. @davkal is there anything we can do? I suspect we're going to have to rework the app <-> UI websocket when pipes come along, so we could delay the work until then.

[davkal]

@tomwilkie I was waiting for something like this to come up. I've been meaning to look into GraphQL, or Netflix's Falcor for this. But then again maybe this is overblown. Until then we can send arbitrary messages along the websocket, in addition to node set changes.

[tomwilkie]

I think for pipes we're going to need the websocket to be 'stationary' - ie not connected / disconnected for every topology the user clicks. If so, the websocket protocol might need to evolve to something along the lines of the UI 'subscribing' to interesting 'channels' - such as the rendered topology updates, node detail updates, pipes etc. Just a though, lets move this discussion off this PR.

[davkal]

Yes, the current implementation with one websocket per topology is not optimal. It's a garbled REST approach. Maybe we can transition to a single socket.io connection that will also have built-in fallbacks if websockets are not supported somewhere along the wire.

[tomwilkie]

The failure was unrelated (and is now fixed). This should be ready for review.

[paulbellamy]

LGTM, then.