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
