Fix a nasty docker/mkvnode.pl race inspired by bootvnodes/vnodesetup.
This is probably true for Xen too, but in some cases, the vnodesetup early-release hackwaitandexit timeout of 30 seconds causes a race condition. Normally, the first node sets up significant network state, and sometimes flips MAC addresses around from interface to interface -- OR puts a physical interface into a bridge, then changes the bridge's MAC address. There is a short window of time where both the bridge and the new member interface share a MAC address -- and if the tmcc ifconfig assembly process for vnodes following the first vnode resolves the wrong device's MAC address and uses that to flesh out the ifconfig info, the vnodesetup will be in a world of hurt (i.e., you might see an attempt to make a vlan device out of a vlan device). The chance of this happening is miniscule, but I've seen it. So, at least for docker for now, we protect the first vnode against the 30-second timeout in vnodesetup hackwaitandexit, and we wait for the actual running file to be written, or error. This is probably applicable to any linux mkvnode.pl path, but I suppose it would have been another hundred thousand vnode creates before I saw it again.
Showing with 61 additions and 15 deletions