[OVSDB-144] plugin set two controller's for integration bridge Created: 31/Mar/15 Updated: 26/Jun/15 Resolved: 26/Jun/15 |
|
| Status: | Resolved |
| Project: | ovsdb |
| Component/s: | Plugin |
| Affects Version/s: | unspecified |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Anil Vishnoi | Assignee: | Anil Vishnoi |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 2925 |
| Priority: | Normal |
| Description |
|
In my two node openstack setup, when i try to connect my compute node ovsdb instance to controller, i see that controller sets two controller value for the integration bridge. I can easily recreate this issue, after 2-3 attempts. root@ComputeNode:~/openstack-setup# ovs-vsctl show |
| Comments |
| Comment by Anil Vishnoi [ 31/Mar/15 ] |
|
The root cause of this problem is a race condition while setting up the openflow controller for bridge. When ovsdb node connects to the controller, it generate NODE event, that results in creating br-int and setting up the OF controller. Once bridge table is modified with br-int entry, it generate table update for Bridge table. Ovsdb Plugin receives this table update and it's default behavior is to set of controller for any new bridge, so when it gets the bridge table update, it again tries to set the openflow controller for the same bridge (br-int) and that causes the race condition, given that both the actions happens in two separate thread. Following are the two stack that try to set the OF controller for the bridge when ovsdb node connects to the controller first time. 1) 2) Second stack is the one that set's the OF controller for any new bridge. Although setOFController check for the existing controller, but it checks the internal cache for that, and internal cache won't get updated till controller gets the update from ovsdb node for Controller table update. So this race condition happens in the duration between controller sent the "set controller for br-int" to ovsdb-node and it gets updated in internal cache. From Openstack integration perspective, i think we should not explicitly set controller for each bridge that we find on ovsdb node. I am referring to following code in InventoryServiceImpl.java private void handleOpenVSwitchSpecialCase(final Node node, final String databaseName, final String tableName, final UUID uuid) { catch (InterruptedException | ExecutionException e) { e.printStackTrace(); } } Above method is called from method processTableUpdates() in the same class if (update.getNew(uuid) != null) { } Once i disable "setting OF controller for every new bridge" behavior, it fixes the issue. IMO assuming that compute node ovsdb instance will be clean (no bridges) before it connects to the controller is absolutely fine. After that ovsdb instance will only persist the configuration that is created by controller. This will give more controlled environment for controller to make sure that things work as expected. |
| Comment by Anil Vishnoi [ 31/Mar/15 ] |
|
If any external project wants to enable the behavior of setting OF Controller for every new bridge, they can override the value in controller config file to enable that. Although it's good if that can be exposed through config sub system rather then a config file. |
| Comment by Anil Vishnoi [ 31/Mar/15 ] |
| Comment by Flavio Fernandes [ 31/Mar/15 ] |
|
(In reply to Anil Vishnoi from comment #1) catch (InterruptedException | ExecutionException e) { > e.printStackTrace(); > }> } > } Very good catch, Anil! I don't think we can assume there are no bridges in |