[GENIUS-116] Use port reason flag to determine the node availablity Created: 27/Feb/18  Updated: 02/Mar/18  Resolved: 01/Mar/18

Status: Verified
Project: genius
Component/s: General
Affects Version/s: None
Fix Version/s: Oxygen

Type: Bug Priority: Highest
Reporter: Arunprakash D Assignee: Suja T
Resolution: Done Votes: 0
Labels: patch_merged
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by OPNFLWPLUG-963 Update port reason flag in datastore ... Verified

 Description   

Instead of reading from config inventory to determine the status of the node availability, use the port reason flag from nodeconnector.

 

port reason == DELETE, when port is deleted from the oper inventory and 

port reason == ADD/UPDATE when the node itself deleted from the oper inventory



 Comments   
Comment by Suja T [ 27/Feb/18 ]

The review link:

https://git.opendaylight.org/gerrit/#/c/66502/.

Comment by Faseela K [ 27/Feb/18 ]

As this patch has high importance in scale testing, and random switch connects and disconnects

Comment by Faseela K [ 28/Feb/18 ]

When switch randomly connects and disconnects, with the current MD-SAL based openflowplugin model, the node gets deleted resulting in sending a slurry of node connector delete and add events to the applications. This is a very potential scale issue, as there will be a lot of applications listening on port delete and add events to handle their flow programming logic.

The fix in openflowplugin makes sure that a PortReason flag comes along with port removal event, which helps in distinguishing between a port removal and a node removal. The corresponding fix in genius makes use of this flag to handle genuine port deletes

Comment by Kit Lou [ 28/Feb/18 ]

Please merge the patch to master and cherry pick to the oxygen branch.

Comment by Michael Vorburger [ 01/Mar/18 ]

klou https://git.opendaylight.org/gerrit/#/c/68794/ is cherry-picked and +2 ready for merge to Oxygen...

Generated at Wed Feb 07 19:59:57 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.