Arun, It is not “installation by boot features property”, but it is “the features that are installed along with infrautils.ready”. If you even install manually the first feature that includes infrautils.ready, you will get system ready notification as expected. But if you install one more feature after a long gap, there won’t be any state change notification, it is still a work in progress. Thanks, Faseela
From: Michael Vorburger [mailto:[email protected]] Sent: Friday, November 24, 2017 4:42 PM To: D Arunprakash <[email protected]> Cc: Muthukumaran K <[email protected]>; Faseela K <[email protected]>; [email protected]; [email protected]; Dayavanti Gopal Kamath <[email protected]>; Tom Pantelis <[email protected]> Subject: Re: [openflowplugin-dev] Proposing infrautils.ready integration for openflowplugin On Fri, Nov 24, 2017 at 7:39 AM, D Arunprakash <[email protected]<mailto:[email protected]>> wrote: What will happen if we install features manually with some time delay between each others? Like install Openflowplugin feature and give some time delay and then install the next features (may be an application)? Will the notification be received twice? No. infrautils.ready, on top of which infrautils.diagstatus is built, currently only serves the simple "installation by boot features property" approach. It basically does a polling of the OSGi APIs (using odlparent.bundlestest FYI), one time during start up. In theory it would certainly be possible to extend infrautils.diagstatus => infrautils.ready and it's org.opendaylight.infrautils.ready.SystemReadyListener's onSystemBootReady() with an onSystemIsChanging() and onSystemReadyAgain(). But in the primary use case I have to support (downstream), "hot" installing additional ODL application features during operational uptime is not a real world requirement. If this is important to you, then your contributions for this would certainly be welcome. Regards, Arun From: [email protected]<mailto:[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
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
