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]> 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]] > *Sent:* Tuesday, February 23, 2016 4:21 PM > *To:* Muthukumaran K > *Cc:* Shuva Jyoti Kar; [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]> wrote: > > So, Routed-RPC-Registration step followed by Oper DS Update step happen > after this ? > > > > *From:* [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] > *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]> 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
