Hi all, Thanks for reviewing the patch, and giving comments. But there is a comment from Robert that this adds dependency of a mature project to an incubation project ☺ Would like to know whether it is completely not possible. In that case, we have to find out other ways to achieve this.
Thanks, Faseela From: Tom Pantelis [mailto:tompante...@gmail.com] Sent: Thursday, October 12, 2017 4:28 PM To: Faseela K <faseel...@ericsson.com> Cc: Anil Vishnoi <vishnoia...@gmail.com>; Muthukumaran K <muthukumara...@ericsson.com>; infrautils-...@lists.opendaylight.org; controller-dev@lists.opendaylight.org; R Srinivasan E <r.e.sriniva...@ericsson.com>; Dayavanti Gopal Kamath <dayavanti.gopal.kam...@ericsson.com> Subject: Re: [controller-dev] Expose Datastore health to applications via infrautils.diagstatus On Thu, Oct 12, 2017 at 6:36 AM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: So here is how diagstatus module works – any application should register as a “service” with the framework, report an initial status(using the APIs provided by diagstatus). There is another OsgiService “ServiceStatusProvider” exposed, and if applications implement the same, that will be called everytime an external request is made to get the current service status. In looking at the API, it appears an app would register with the DiagStatusService and invoke report each time its status changes. An app can also register a ServiceStatusProvider to report its status when queried. It seems this is an alternative to interacting with the DiagStatusService in looking at the DiagStatusServiceImpl which always calls updateServiceStatusMap to query the ServiceStatusProviders from the get* methods. Given that, why would an app need to explicitly register and push its status to the DiagStatusService? Why not just advertise a ServiceStatusProvider? This seems simpler. In that case, DiagStatusServiceImpl doesn't need to maintain the statusMap - it would just query the ServiceStatusProvider(s) on demand. Or am I missing something? For services like “DATASTORE” only the pull model is required, just register the service and implement ServiceStatusProvider. There are some usecases in genius, where a push model was preferred, and hence we have kept both the options open. OK. By "just register the service" I assume you mean just advertise a ServiceStatusProvider OSGi service. It is not necessary to explicitly register with the DiagStatusService as that is implicit by advertising a ServiceStatusProvider. The code in DiagStatusServiceImpl does not enforce explicit registration - one can just call report w/o a prior register call - not sure if that was the original intent. Similarly a ServiceStatusProvider's status is reported even if it didn't explicitly call register. Right Tom, the original intent was to allow only services who do explicit registration. But it is not enforced yet, wanted to get inputs on how the apps would be interested to go about this. Michael recently modified the implementation to allow deregistration only for those who actually registered. We were thinking on enforcing the same everywhere, but just thought of sharing the idea to apps before doing the same. It seems the only reason for explicit registration would be to remove it from being reported on unregistration. But this could also be effected by reporting that as a STOPPED status, which might be useful to report. In any event, explicit reg/unreg via the DiagStatusService API would only be needed/enforced when pushing status. Advertising a ServiceStatusProvider OSGi service is an implicit registration and removal of the OSGi service is an implicit unregistration. Thanks, Faseela
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
