Hi Anil, On Mon, Dec 11, 2017 at 11:16 PM, Anil Vishnoi <[email protected]> wrote:
> 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 ). > I've used this thread as the opportunity to finally write some real documentation about what infrautils.ready actually is and does - and what it's not; see https://wiki.opendaylight.org/view/Infrastructure_Utilities:Main#Ready_service - hopefully this answers some of the Qs raised on this thread? So infrautils.ready is what you named a "system ready" API. It has absolutely nothing to do with infrautils jobcordinator (your Q above), why would it? It knows nothing about the data store. Nor clustering. I'm happy to answer any remaining questions about this module, should the new documentation leave anything un-answered. Now infrautils.diagstatus is a higher-level module. It internally uses infrautils.ready, but has a notion of feature diagnostic information that it can pull at runtime. It has a CLI command that can query cluster nodes. Faseela can provide more information about this module. Tx, M. -- Michael Vorburger, Red Hat [email protected] | IRC: vorburger @freenode | ~ = http://vorburger.ch > >> >> 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; >> [email protected]; [email protected] >> ght.org; 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] >> aylight.org >> *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]>; [email protected] >> aylight.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]>; [email protected] >> aylight.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 > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
