On Mon, Oct 23, 2017 at 2:37 PM, Tom Pantelis <tompante...@gmail.com> wrote:
> 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? ... > If this just about writing the word "mature" instead of "incubting" somewhere (where?) then let's do it.. PS: Personally I think these sort of things are fairly meaningless, so I have little interest in them. > 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. >>> >>
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
