On Mon, Oct 23, 2017 at 8:35 AM, Tom Pantelis <tompante...@gmail.com> wrote:
> > > 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. > > Or we get infrautils promoted to "mature" to get around the red tape. What would that take? ... > >> >> 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
