On Thu, Oct 12, 2017 at 1:38 AM, Faseela K <faseel...@ericsson.com> wrote:
> I had the same discussion with Michael. > > Since infrautils is placed as some entity below controller/md-sal, he had > the opinion that the service should be registered from above and the status > should be exposed. > Yeah, we had brief discussion about it in DDF, and i think that's the ideal way to do it. > 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. > Isn't it that in both the approach, controller will have to depend on infrautils? > > > Thanks, > > Faseela > > > > *From:* Anil Vishnoi [mailto:vishnoia...@gmail.com] > *Sent:* Thursday, October 12, 2017 2:04 PM > *To:* Faseela K <faseel...@ericsson.com> > *Cc:* Muthukumaran K <muthukumara...@ericsson.com>; Tom Pantelis < > tompante...@gmail.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 > > > > Given that we are relying on MBean info to determine the readiness, does > it matter whether it's should be part of the controller or a service in > infrautils? Given that data store is core service, probably writing a > service in infrautils is probably not a bad idea . > > > > With the current MBean exposed by controller, i think it does not support > MBean notification ( i might be wrong), but if we can enable MBean > notification, it will be like a status published through controller, it's > just that in infrautils we need to make sense out of the changes. > > > > On Thu, Oct 12, 2017 at 1:24 AM, Faseela K <faseel...@ericsson.com> wrote: > > Thanks Muthu, Tom! > > Now the only question is whether CONTROLLER can depend on INFRAUTILS to > implement the ServiceStatusPoller OsgiService, so that we will have one > single point where all major service status will be available. > > > > Thanks, > > Faseela > > > > *From:* Muthukumaran K > *Sent:* Thursday, October 12, 2017 1:52 PM > *To:* Tom Pantelis <tompante...@gmail.com> > *Cc:* Faseela K <faseel...@ericsson.com>; infrautils-dev@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 > > > > Thanks Tom. Then we would use the aggregate SyncStatus at Shard-Manager > level. > > > > If we need to further drill down at shard-level (I do not have a usecase > readily for that though) we can use Shard Level MXBeans anyway for any > manual troubleshooting > > > > Regards > > Muthu > > > > > > *From:* Tom Pantelis [mailto:tompante...@gmail.com <tompante...@gmail.com>] > > *Sent:* Thursday, October 12, 2017 1:05 PM > *To:* Muthukumaran K > *Cc:* Faseela K; infrautils-...@lists.opendaylight.org; > controller-dev@lists.opendaylight.org; R Srinivasan E; Dayavanti Gopal > Kamath > *Subject:* Re: [controller-dev] Expose Datastore health to applications > via infrautils.diagstatus > > > > > > > > On Thu, Oct 12, 2017 at 3:08 AM, Muthukumaran K < > muthukumara...@ericsson.com> wrote: > > Hi Tom, > > > > While the initial status of the CDS is inferable using the aggregate > SyncStatus, for dynamic status (eg. after startup, leader mobility in > cluster due to load, availability scenarios like node-loss etc.), we were > thinking of explicitly checking if all configured shards do have the leader > or not (of course using the Shard Level MBeans). > > > > But, from your mail, I understand that aggregate SyncStatus being set to > false can be a more easier way to address dynamic changes post start > instead of doing shardwise checking. > > > > Is my understanding correct ? > > > > > > That is correct. The shard will report a sync status change if it's a > follower and the leader changes or if it goes to candidate. Of course if > it's the leader, its sync status is automatically true. Also a follower > shard will report it's not in sync if it lags behind the leader by a > certain # of commits (default 10). > > > > Regards > > Muthu > > > > > > *From:* controller-dev-boun...@lists.opendaylight.org [mailto: > controller-dev-boun...@lists.opendaylight.org] *On Behalf Of *Tom Pantelis > *Sent:* Thursday, October 12, 2017 12:28 PM > *To:* Faseela K > *Cc:* infrautils-...@lists.opendaylight.org; controller-dev@lists. > opendaylight.org; R Srinivasan E; Dayavanti Gopal Kamath > *Subject:* Re: [controller-dev] Expose Datastore health to applications > via infrautils.diagstatus > > > > > > > > On Wed, Oct 11, 2017 at 2:16 PM, Faseela K <faseel...@ericsson.com> wrote: > > Hello controller-dev, > > > > We @ infrautils have developed a status-and-diagnostics framework, > where applications can register their services, > > And report when they are functionally up. Northbound and Southbound > interfaces for ODL can open-up and accept configurations, > > When all the required services are UP. As part of this, we were > thinking if we can have a “DATASTORE” service, whose status can > > Be shown as “OPERATIONAL” when all the shards have properly elected > their leaders. We do see that there are several MBeans exposed by > controller repo under *org.opendaylight.controller:Category=Shards,name="* > +*<shard-name>*+*",type=DistributedConfigDatastore* > > which can be used to derive the same information. > > Instead of doing that from outside, wanted to explore the possibility > of integrating controller.sal-distributed-datastore with > infrautils.diagstatus to report the status when the initial shard leader > election is complete, > > And implement the dynamic poll interface to fetch the shard leader > status at random points in time. Please share your thoughts. > > > > This sounds like a reasonable idea. CDS does have an aggregated shard > sync status that is collected and reported by the ShardManager to > the ShardManagerInfo MBean's SyncStatus attribute for each data store (eg > *type=DistributedConfigDatastore,Category=ShardManager,name=shard-manager-config*). > Once all shards report that they are "in sync" (ie a leader is elected and, > if it's a follower, its journal is up-to-date with the leader), the > ShardManager sets the aggregate SyncStatus to true. Subsequently, if a > shard loses its leader, the aggregate SyncStatus will be set to false. > > > > I'm not really familiar with infrautils.diagstatus to know how exactly how > this status would be reported to that component. This would also require > the controller project to be dependent on infrautils - not sure if that > would be OK? > > > > Also, separate from SyncStatus, CDS blocks its blueprint startup until all > shards have elected a leader (up to 90 sec) so its OSGi services aren't > advertised until then. Therefore all bundles that import those services > will also be blocked on startup. > > > > > > > > Thanks, > > Faseela > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > > > > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > > > > > -- > > Thanks > > Anil > -- Thanks Anil
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
