Gracefully handle network bridge without IP association at startup#8453
Conversation
|
ping @aluzzardi |
There was a problem hiding this comment.
Is there a more robust way to check this error rather than doing a string matching?
There was a problem hiding this comment.
It would be nice to have a cleaner way to check for bridge existence, and I looked into that first before ending up with this solution. At this point, to do something more like a bridge existence check rather than test for error we would need a new API in libcontainer netlink layer similar to what you can do with brctl show to query a bridge.
The "file exists" response is a well-known return from the RTNETLINK layer, not something from Go and/or Docker, so is presumed quite stable as far as depending on it to not change in Linux as a syscall response.
There was a problem hiding this comment.
Probably cast to syscall.Errno and compare to syscall.EEXIST
There was a problem hiding this comment.
Since this error is thrown by the syscall, would os.IsNotExist work here?
There was a problem hiding this comment.
Ah nice--I'm new enough to Go to have no idea that existed (no pun intended). I can test and verify.
c880ff6 to
0008a0a
Compare
|
Thanks for the help-- |
|
Tests seem to be failing, please have a look at the drone link. |
|
hrm.. @aluzzardi no idea why--tests passed here 4 times, but Jess offered to restart on drone and it was successful |
|
Awesome. I know this is may not be feasible given the current testing framework we have, but could you look around in unit tests / integration tests to see if it would be possible to add a test for this? |
|
Thought about tests while I was looking into this. Could be my lack of understanding of the tests but I'm not sure how to set up the right environment and test that the daemon either starts properly or fails--which is what would be required in this case. I need |
|
here is an example of a daemon restart ttest: On Tue, Oct 7, 2014 at 6:21 PM, Phil Estes [email protected] wrote:
|
|
Thanks @jfrazelle for the pointer--I know what to do now :) I'll see if I can get a test working and add to this PR |
0008a0a to
1150f04
Compare
|
ping @aluzzardi @jfrazelle test added. PTAL |
There was a problem hiding this comment.
what sucks is if we fail after this to recreate the bridge will all the other test be screwed... I would rather have that I think than no test at all but idk
There was a problem hiding this comment.
If there is worry about destroying the environment, a simple brctl delbr docker0 added to the failure path will make sure that any future daemon starts will work even without the fix for this issue. However, I wasn't sure about the environment this test is running in--whether I could/should depend on brctl being available. Another option is to save the IP and restore in the failure path.
|
Now that the 1.3.0 push is over, any followup comments or concerns on this PR? @aluzzardi @jfrazelle |
|
I would rather have a test than no test at all so LGTM but maybe we should add a fix me explaining what happens when the test fails |
|
especially in the Error for when it fails, so if it does other people aren't hunting down why the network became all screwy EDIT: sorry clicked the wrong button below... |
1150f04 to
6ed75ec
Compare
|
good point--added a big "WARNING**" string to the error log output; let me know if you want it formatted differently |
|
ah perfect thanks |
4934d2e to
8482897
Compare
Addresses moby#8444 Docker-DCO-1.1-Signed-off-by: Phil Estes <[email protected]> (github: estesp)
8482897 to
1262b5f
Compare
|
rebased, drone failures, sweated over tests, fixed tests, rebased again.. now I hope this is actually ready to merge now :) @aluzzardi have you had a chance to look at this? |
|
Awesome, thanks for adding tests. LGTM |
Gracefully handle network bridge without IP association at startup
Addresses #8444
Docker-DCO-1.1-Signed-off-by: Phil Estes [email protected] (github: estesp)