[OVSDB-451] Multiple topology node entries for same Ovsdb instance not recovered on controller restart Created: 15/Feb/18  Updated: 16/Feb/18

Status: Open
Project: ovsdb
Component/s: Southbound.Open_vSwitch
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: Helen Florida John Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File ovsdb-karaf.log    

 Description   

Create 3 sessions with 3 different node-ids from the controllers with an ovsdb instance.
Topology shard shows 3 entries.
Restart controller
Only 1 session is retained and the other 2 are not with the below warn
```2018-02-13 16:26:50,449 | WARN | on-dispatcher-62 | OvsdbDataTreeChangeListener | 414 - org.opendaylight.ovsdb.southbound-impl - 1.5.1 | Connection to device ConnectionInfo{getRemoteIp=IpAddress [_ipv4Address=Ipv4Address [_value=10.18.130.109]], getRemotePort=PortNumber [_value=6634], augmentations={}} already exists. Plugin does not allow multiple connections to same device, hence dropping the request OvsdbNodeAugmentation{getConnectionInfo=ConnectionInfo{getRemoteIp=IpAddress [_ipv4Address=Ipv4Address [_value=10.18.130.109]], getRemotePort=PortNumber [_value=6634], augmentations={}}}```
After the restart when we try to create new or existing node-id entries to the same instance the WARN is seen but it also allows the node entries to be created...

 Comments   
Comment by Anil Vishnoi [ 16/Feb/18 ]

I assume you are using different node name but same connection info in all the request? Datastore does not enforce the uniqueness of the connection-info data, so user can put multiple node with different name but same config data, and data store will accept it because it's syntactically correct. Given that configuration in config data store is user intent, even thought it's wrong configuration southbound plugin won't make any changes to the configuration, but it should always reported the excepted operational state of that configuration. In this scenario, plugin should not create multiple session to the ovsdb device because plugin does not allow multiple connection to same device. If you are seeing this behavior, that's a bug.

 

Given that OVSDB plugin should only allow one connection to the device, you should only see operational status only for one node-id in the operational data store. So expected programming model here is that application should check the operational state of connection from operational status and also make sure that they are not creating multiple session to the same device, because plugin will internally ignore the request.

This behavior can be further improve by using the Commit Cohort functionality, where a semantic check can be done to check if the new connection request is asking a new session to already connected OVSDB instance, if yes, commit cohort should reject that request with appropriate error code.

Comment by Helen Florida John [ 16/Feb/18 ]

Yes, I am using different node names to the same connection..

Based on your explanation given above I went back and noticed that even though the operational data store has entries for every different node however the connection status is seen only on the first one..

It would be good if the improvement mentioned can be done cause the behavior is not the same before controller restart and after controller restart.. 

So before start the controller makes the entries in the operational shard for all nodes however creates only one connection as active status and the rest it has no connection status information. After restart, the controller allows only the first node-id connection and rejects the remaining ones and the same is reflected in the operational shard.. I think the behavior of controller after restart should be similar before start avoid to avoid the entries of additional node-ids in the operational shard.. Please let me know your thoughts... Below is the output seen when it allows multiple node-id connections..

<topology>
<topology-id>ovsdb:1</topology-id>
<node>
<node-id>ovsdb:6</node-id>
<openvswitch-external-ids xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<external-id-key>system-id</external-id-key>
<external-id-value>09896aaa-0386-4517-a4d4-538119ab16a9</external-id-value>
</openvswitch-external-ids>
<openvswitch-external-ids xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<external-id-key>opendaylight-iid</external-id-key>
<external-id-value>/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:6']</external-id-value>
</openvswitch-external-ids>
<connection-info xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<local-port>39354</local-port>
<remote-ip>10.18.130.109</remote-ip>
<remote-port>6634</remote-port>
<local-ip>10.18.130.45</local-ip>
</connection-info>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-lisp</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-stt</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-tap</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-internal</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-patch</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-vxlan</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-system</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-ipsec-gre</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-gre</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-geneve</interface-type>
</interface-type-entry>
<db-version xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">7.12.1</db-version>
<ovs-version xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">2.5.1</ovs-version>
<datapath-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<datapath-type>datapath-type-system</datapath-type>
</datapath-type-entry>
<datapath-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<datapath-type>datapath-type-netdev</datapath-type>
</datapath-type-entry>
<manager-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<target>ptcp:6634</target>
<number_of_connections>1</number_of_connections>
<connected>true</connected>
</manager-entry>
</node>
<node>
<node-id>ovsdb:7</node-id>
<openvswitch-external-ids xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<external-id-key>system-id</external-id-key>
<external-id-value>09896aaa-0386-4517-a4d4-538119ab16a9</external-id-value>
</openvswitch-external-ids>
<openvswitch-external-ids xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<external-id-key>opendaylight-iid</external-id-key>
<external-id-value>/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb:7']</external-id-value>
</openvswitch-external-ids>
<connection-info xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<local-port>39354</local-port>
<remote-ip>10.18.130.109</remote-ip>
<remote-port>6634</remote-port>
<local-ip>10.18.130.45</local-ip>
</connection-info>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-lisp</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-stt</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-tap</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-internal</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-patch</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-vxlan</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-system</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-ipsec-gre</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-gre</interface-type>
</interface-type-entry>
<interface-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<interface-type>interface-type-geneve</interface-type>
</interface-type-entry>
<db-version xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">7.12.1</db-version>
<ovs-version xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">2.5.1</ovs-version>
<datapath-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<datapath-type>datapath-type-system</datapath-type>
</datapath-type-entry>
<datapath-type-entry xmlns="urn:opendaylight:params:xml:ns:yang:ovsdb">
<datapath-type>datapath-type-netdev</datapath-type>
</datapath-type-entry>
</node>
</topology>

Generated at Wed Feb 07 20:36:26 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.