Proposal: Add post-start container-checks

[funkyfuture]

As described in #854 under undetermined circumstances it is possible that a started container will not have a network-bridge-interface attached.
it is obviously not Compose's 'fault', but imo it should be aware of it and inform the user.
therefore Compose should inspect whether a just-started container has all options it was invoked with. if there is a discrepancy it should abort all services and inform the user what that discrepancy was.

furthermore there could be a retry-option, which would make sense in development-environments since they are more likely to fail due to often changing system-settings, like VPNs in my case.

if there is affirmative feedback, i'm willing to work on that.

[bfirsh]

Do you think this could be in Docker itself?

[funkyfuture]

yes, i think that would be possible and naturally the way to go.

however there were mainly two motivations for my proposal:

• i could implement it in Compose, as i don't 'speak' Go
• Compose as an orchestrator should also have an interest to health-check what it dispatches

another reason that makesit difficult to open an issue for Docker is, that the behaviour described in #854 never occurred when i used only Docker without Compose. but i didn't often use it that way, neither did i check it systematically like with Compose.

in case i would implement it for Compose, the health-checks would have to be explicitly set by an option.

myself, i am in an ambivalence here. on the one hand it is Docker's responsibility to run as intended. on the other, race time conditions can always occur, have an unpredictable source/outcome and the orchestrator should notice that something's wrong and inform the user or client code.

[dnephin]

I think events makes this possible. What do you think about using #1510 for this?

[funkyfuture]

yep, that's suitable.