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-...@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] Sent: Thursday, October 12, 2017 1:05 PM To: Muthukumaran K Cc: Faseela K; infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>; controller-dev@lists.opendaylight.org<mailto: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<mailto: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> [mailto: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<mailto:infrautils-...@lists.opendaylight.org>; controller-dev@lists.opendaylight.org<mailto: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<mailto: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<mailto: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
