Tolerate multiple OvS bridges on the same host#120
Conversation
Make OvS network fabric tolerate multiple bridges on the host when listing all pre-existing local network interfaces connected to its bridge.
| // rather than one separate command per interface). | ||
| func (f *ovsFabric) newGetIfcsOFPortsCmd(ifcs []string) *exec.Cmd { | ||
| cmdArgs := []string{"get", "interface"} | ||
| ifcsJoinedForCmd := strings.Join(ifcs, " ofport -- get interface ") |
There was a problem hiding this comment.
Consider the "--" between "ofport" and "get interface".
It is "ovs-vsctl" syntax for executing multiple commands (separated by "--") within a single transaction.
Within a single transaction also means within a single command which also means a single fork + exec.
This approach is more scalable than the more intuitive approach of retrieving the OpenFlow port number for each interface separately (1 fork + exec for every interface); see here for a sloppy perf comparison.
The drawback is that we're conflating logically independent commands in a single transaction, if there are many of them the likelihood of at least one of them failing increases and if that happens the whole command fails. But OvS has a reputation for being very reliable, so IMO it is worth it.
matte21
changed the title
1 participant
Before this PR the OvS network fabric does NOT tolerate the existence of other OvS bridges on its host (besides its own OvS bridge) when listing pre-existing local network interfaces.
"Does not tolerate" means that it considers pre-existing local network interfaces connected to OvS bridges other than its own as connected to its own OvS bridge, and this means that in certain scenarios it can delete such "external" network interfaces.
This PR fixes that behavior: the OvS fabric now only considers pre-existing local network interfaces connected to its own bridge.
This PR is orthogonal to #119.