Please see inline.. On Sat, Dec 9, 2017 at 11:06 PM, Muthukumaran K <[email protected] > wrote:
> 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. > Agree, application readiness depends on the business logic it's running, so we can't take any assumption here. > > > **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. > Agree, but i am wondering if somebody really hit this issue, because i haven't seen this in carbon/nitrogen. Apart from that how system.ready determines that data store is ready, because in the current implementation of system.ready , i don't see anything that is doing any explicit check (totally possible that i missed it in code). > > This may not be only required during startup. But what happens if dependent > you missed writing something here? > > > 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. > or data store itself can notify that it's ready for the business, so applications don't even need the middleman to atleast notify the platform readiness. > > > **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) ? > That depends on what feature the application is using? If application is not using the datastore, it might be okay if the data store is not available (assuming no routed rpc is being used), also in some cases disconnecting the switches also might be a reasonable solution. I think having a middleman that provides you these API's is all goodness, my concern is the scope of the API. My main question here is what "system.ready" api consider as a system ready? Is it just a data store or it's scope is wider than that ? Is checking infrautils jobcordinator service is up can also be a part of system.ready? Also these API's need to provide the guarantee that they won't provide false positive notification when it comes to clustering and specially when cluster is in split brain situation. Given that infrautils is an external monitor, getting the correct state of cluster is not that easy when it comes to the split brain scenario, because your JMX bean also might not be updated with latest state. Although this is not immediate concern, but something to keep in mind. Now assuming that scope of system.ready is to just check the base platform (mdsal data store readiness) wondering why not push this feature to controller project itself? So if any external application writing something on base platform can leverage it directly, rather then relying on infrautils (assuming user is aware of infrautils project ). > > > Hope we are in sync > > > > Regards > > Muthu > > > > > > > > > > > > > > > > *From:* Anil Vishnoi [mailto:[email protected] <[email protected]>] > > *Sent:* Saturday, December 09, 2017 6:12 AM > *To:* Vishal Thapar > *Cc:* Faseela K; Muthukumaran K; D Arunprakash; openflowplugin-dev@lists. > opendaylight.org; [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]> 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]] *On Behalf Of *Faseela > K > *Sent:* 27 November 2017 12:06 > *To:* Muthukumaran K <[email protected]>; D Arunprakash < > [email protected]>; [email protected] > > > *Cc:* [email protected]; Dayavanti Gopal Kamath < > [email protected]>; Tom Pantelis <[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]>; Faseela K < > [email protected]>; [email protected] > *Cc:* [email protected]; Dayavanti Gopal Kamath < > [email protected]>; Tom Pantelis <[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] > *Cc:* [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] > <[email protected]>] *On Behalf Of > *Muthukumaran > K > *Sent:* Thursday, November 23, 2017 11:19 AM > *To:* Faseela K <[email protected]>; openflowplugin-dev@lists. > opendaylight.org > *Cc:* [email protected]; Dayavanti Gopal Kamath < > [email protected]>; Tom Pantelis <[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] > *Cc:* [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]>; openflowplugin-dev@lists. > opendaylight.org > *Cc:* [email protected]; Sam Hague <[email protected]>; > Dayavanti Gopal Kamath <[email protected]>; Vivek > Srivastava V <[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] > *Cc:* [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] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > > > > > > -- > > Thanks > > Anil > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
