Hi Anil, Adding to your point, checking whether “all other” components (how the list is even decided ??) than datastore itself are ready or not to decide to make OFPlugin active, is something which would not be acceptable for all projects. Applications may choose to be not ready for business (eg. an application may choose to defer registering DTCLs until some other condition is met and would not be ready to receive events from DS, may be performing some async initialization task etc. , after their startup) even if bundle-statuses appears fine.
*From OFPlugin perspective* The key requirement is that the ofplugin does not prematurely open up the ports for DPNs to connect unless datastore is ready. Hope you agree on that part Readiness of datastore in cases of nodal reboot and clusterwide reboot (building schema context for known features, restoring data from persistence and other initialization tasks) would be a pre-requisite for OFPlugin to declare itself as “ready for business” – in other words, open the OF ports floodgates. This may not be only required during startup. But what happens if dependent Now, if we agree that the DS dependency is meaningful for OFPlugin, we can examine below points *A better “sensor” for finding readiness of datastore using pull-model* A higher-level and authentic “sensor” can be ShardManager MBean’s syncstatus attribute which gets set to true when datastore becomes “open for business” (well, we can get more fine-grained in examining only the shards which matter to OFPlugin only – but that depends upon deployments again, and we speak about only what is the default shard strategy as it stands today). Having said that, we have two possibilities *Option 1* : OFPlugin directly inspect this MBean attribute - this approach may be frowned-upon from design perspective since it does not follow any specific contractual API and may set a precedence to access any JMX MBeans from any module. *Option 2* : Some middleman hides the JMX Mbean access and exposes via a defined API with push (event-based) as well as pull semantics. Now, who could be this middleman – infrautuils’ system.ready or enhanced system.ready or somebody else ? is something which needs to be decided. *One open question remains though* In case, after openflowplugin becomes fully functional, if for some reason, datastore becomes unavailable, should / should not OFPlugin stop its functionality (intrusively, disconnect the switches if that is not awfully destructive) ? Hope we are in sync Regards Muthu From: Anil Vishnoi [mailto:[email protected]] Sent: Saturday, December 09, 2017 6:12 AM To: Vishal Thapar Cc: Faseela K; Muthukumaran K; D Arunprakash; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Dayavanti Gopal Kamath; Tom Pantelis Subject: Re: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin Sorry for jumping late on this feature. So looks like openflowplugin now is pulling infrautils features to consume the system.ready functionality. Now assume a scenario, where BGP project also moved to infrautils system.ready service and user install the bgp feature first and then openflowplugin features, will the system.ready service work in this case (openflowplugin will get notification)? Looking at the system.ready state service, looks like it currently just looking at the bundles and if they are up in 5 minutes it notifies listener that system is ready. How is it different then the way karaf currently loads the bundles/features? Just trying to see the value-add here for relying on the system.ready service. Also looks like if for some reason some bundle does not come up in 5 minutes (for valid reasons) it will end up failing the system and openflowplugin won't start, which if you rely on just karaf loading, won't happen. is there any plan to further extend the check that system.ready does to ensure the system is ready? Because with the current integration it doesn't look like it's getting much from putting dependency on one more project. On Sun, Nov 26, 2017 at 10:44 PM, Vishal Thapar <[email protected]<mailto:[email protected]>> wrote: Humble request: Please don’t add dependency to Genius in OFP. Let us go with system ready for OFP as Muthu mentioned for now. Once we get it in controller use it. Regards, Vishal. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Faseela K Sent: 27 November 2017 12:06 To: Muthukumaran K <[email protected]<mailto:[email protected]>>; D Arunprakash <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dayavanti Gopal Kamath <[email protected]<mailto:[email protected]>>; Tom Pantelis <[email protected]<mailto:[email protected]>> Subject: Re: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin Hi Arun, DATASTORE service patch was initially proposed in controller, and we need to work on some more documentation stuff in infrautils to get this there finally. Genius is just a temporary placeholder for the same, till things get sorted out. Thanks, Faseela From: Muthukumaran K Sent: Monday, November 27, 2017 11:47 AM To: D Arunprakash <[email protected]<mailto:[email protected]>>; Faseela K <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dayavanti Gopal Kamath <[email protected]<mailto:[email protected]>>; Tom Pantelis <[email protected]<mailto:[email protected]>> Subject: RE: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin IMO, we can start with system ready to begin with since OFP cannot have Genius as runtime dependency Regards Muthu From: D Arunprakash Sent: Monday, November 27, 2017 11:42 AM To: Muthukumaran K; Faseela K; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dayavanti Gopal Kamath; Tom Pantelis Subject: RE: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin Hi Muthu/Faseela, The datastore service is registered from genius md-sal, if we install only Openflowplugin features then we will have problem to obtain datastore service status. For now, it’s not possible to check datastore service from Openflowplugin using snd framework. We can open the southbound interface based on the system-ready from infrautils. Regards, Arun From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Muthukumaran K Sent: Thursday, November 23, 2017 11:19 AM To: Faseela K <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Dayavanti Gopal Kamath <[email protected]<mailto:[email protected]>>; Tom Pantelis <[email protected]<mailto:[email protected]>> Subject: Re: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin Yes. That would be the right approach and can simplify the check by OFPlugin easier Regards Muthu From: Faseela K Sent: Thursday, November 23, 2017 11:17 AM To: Muthukumaran K; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Sam Hague; Dayavanti Gopal Kamath; Vivek Srivastava V; Tom Pantelis Subject: RE: Proposing infrautils.ready integration for openflowplugin Thanks for the input Muthu! Diagstatus is already integrated to openflowplugin, and hence an additional check can be made to see whether DATASTORE service is operational when system is “ready”, before opening up the southbound interfaces. Thanks, Faseela From: Muthukumaran K Sent: Thursday, November 23, 2017 11:15 AM To: Faseela K <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Sam Hague <[email protected]<mailto:[email protected]>>; Dayavanti Gopal Kamath <[email protected]<mailto:[email protected]>>; Vivek Srivastava V <[email protected]<mailto:[email protected]>> Subject: RE: Proposing infrautils.ready integration for openflowplugin It would be cleaner to include the datastore check apart from just ready state. When the application-features get installed, corresponding yang models are absorbed to build schema context incrementally. There is no absolute telling when this completes depending upon how quick application features get installed (Which in turn depend upon their dependency graph(s)). The schemacontext present at the time of restoration will be used as it is for validating and restoring data during scenarios like reboot. Though most of the apps get installed as part of boot features, it would be better to include this exclusive check in addition to standard ready check Hope we are all in sync Regards Muthu From: Faseela K Sent: Tuesday, November 21, 2017 10:46 PM To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; Sam Hague; Dayavanti Gopal Kamath; Vivek Srivastava V; Muthukumaran K Subject: Proposing infrautils.ready integration for openflowplugin Hi Shuva/Arun As a follow up to diagstatus integration to openflowplugin, I would like to propose the integration of infrautils.ready for openflowplugin. This way openflowplugin can open the southbound ports after all bundles have come up properly. Also diagstatus can fetch the dynamic service status based on the current southbound connection status as well as other criteria. This will help in many cases, including initial system bring up as well as cluster reboot, as there is enough time for all applications to come up gracefully before they start receiving southbound events. Please let us know your thoughts on the same. Thanks, Faseela _______________________________________________ openflowplugin-dev mailing list [email protected]<mailto:[email protected]> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
