Thanks Anil. I think, until routed RPC gossip propagation and perhaps RPC-call serialization aspects improve, local-RPC can remain as norm for FRM and Recon code.
From: Anil Vishnoi [mailto:[email protected]] Sent: Wednesday, February 24, 2016 12:36 AM To: Shuva Jyoti Kar Cc: Muthukumaran K; [email protected] Subject: Re: [openflowplugin-dev] OF HA sequence of Events Operational DS update happens after (6.1), so all applications get node added notification after (6.1). So ideally applications should not call any RPC before (6), given that they don't really know that node is yet connected to the controller. We register the routed RPC earlier at the moment so that in clustered mode we can publish it as soon as possible, but given that we now moved to local rpc implementation, we don't really need that. On Tue, Feb 23, 2016 at 4:02 AM, Shuva Jyoti Kar <[email protected]<mailto:[email protected]>> wrote: So Oper DS Update happens after 6.1 is it ? If it happens any earlier that 6.1 and applications use rpc between 3.1 and 6.1 what is the behavior, as there is a level of uncertainty as to the who owns it. Thanks Shuva From: Anil Vishnoi [mailto:[email protected]<mailto:[email protected]>] Sent: Tuesday, February 23, 2016 4:21 PM To: Muthukumaran K Cc: Shuva Jyoti Kar; [email protected]<mailto:[email protected]> Subject: Re: [openflowplugin-dev] OF HA sequence of Events sorry missed that one 1) Openflowplugin receives the switch connection 2) plugin register that controller as a candidate for device ownership with EOS 3) Plugin fetch the current ownership state of the device, if it does not get the ownership it doesn't do anything, if it gets the ownership state and EOS give ownership to that controller, 3.1) Register Routed RPCs 4) It's sends the master role to the switch else it will send slave role to the switch 5) Once master role is set, it will send nodeAdded() yang notification to the application 6) If master role setting fails,it de-register the candidate for device ownership, so that anyone else can get EOS ownership and it can try for the master role setting. 6.1) Also deregister the router rpc as well On Tue, Feb 23, 2016 at 12:09 AM, Muthukumaran K <[email protected]<mailto:[email protected]>> wrote: So, Routed-RPC-Registration step followed by Oper DS Update step happen after this ? From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Anil Vishnoi Sent: Tuesday, February 23, 2016 5:15 AM To: Shuva Jyoti Kar Cc: [email protected]<mailto:[email protected]> Subject: Re: [openflowplugin-dev] OF HA sequence of Events In Helium plugin, this is how it goes 1) Openflowplugin receives the switch connection 2) plugin register that controller as a candidate for device ownership with EOS 3) Plugin fetch the current ownership state of the device, if it does not get the ownership it doesn't do anything, if it gets the ownership state and EOS give ownership to that controller, 4) It's sends the master role to the switch else it will send slave role to the switch 5) Once master role is set, it will send nodeAdded() yang notification to the application 6) If master role setting fails,it de-register the candidate for device ownership, so that anyone else can get EOS ownership and it can try for the master role setting. On Mon, Feb 22, 2016 at 10:11 AM, Shuva Jyoti Kar <[email protected]<mailto:[email protected]>> wrote: Hi Anil/Kamal, What are the exact sequence of events between EOS receiving a switch connection and the switch data being populated in the Oper DS ? Thanks Shuva -- Thanks Anil -- Thanks Anil -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
