On Mon, Oct 23, 2017 at 5:35 AM, Faseela K <faseel...@ericsson.com> wrote:
> 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 J Would like to know whether it > is completely not possible. In that case, we have to find out other ways to > achieve this. > I don't really know the rules/philosophies/history with incubation projects and dependencies and what it takes or means to be "mature" (or if really matters anymore with ODL). However I don't think we shouldn't let bureaucracy impede progress so I'm fine with the dependency. We should be able to freely use infrautils - prior to it we used yangtools as a kind of dumping ground for generic components (that had nothing to do with yang) b/c we had no where else to put them. infrautils *should* serve that purpose now. But if it's a showstopper then the proposed DatastoreStatusMonitor could actually reside anywhere since it just uses JMX. > > > 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> 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
