From: Tom Pantelis [mailto:tompante...@gmail.com] Sent: Friday, June 08, 2018 1:05 AM To: Faseela K <faseel...@ericsson.com> Cc: Michael Vorburger <vorbur...@redhat.com>; controller-dev <controller-dev@lists.opendaylight.org>; genius-...@lists.opendaylight.org; Robert Varga <n...@hq.sk> Subject: Re: yang notifications to CDS to emit interesting state/status changes
On Thu, Jun 7, 2018 at 3:25 PM, Tom Pantelis <tompante...@gmail.com<mailto:tompante...@gmail.com>> wrote: On Thu, Jun 7, 2018 at 3:20 PM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: Yes, we are currently using EOS in such scenarios. But is there a way to specify that I want my entity owner to be on “default-config shard leader”? No - EOS and shards are different concepts. But you mentioned there's DTCN's from different shards involved, say default-config and default-operational, so that forcing owner to the default-config shard leader wouldn't help you - access to the default-operational shard would still be remote. >> I do have some cases where as a result of the 2 events, whatever I have to read/write are from one shard only. In such cases, it helps if there is a way to force the processing on a specific node of my choice. That’s why I was asking whether the new notifications you are going to add will help in implementing such functionalities. They're not related. Actually the notifications theoretically could be used for some service placement component as Robert mentioned. >> Yes, I was planning to shoot an email to controller-dev about the same thing whatever you are trying to implement. I can even have a cache in my module, which stores the shard leader information, and use clustered DTCNs and process the event only on the node which is the leader. The cache can be updated everytime a notification comes for shard leader change. Looks similar to EOS, but I am not sure how robust it will be if shards are moving, or in a jeopardy state. Thanks, Faseela From: Tom Pantelis [mailto:tompante...@gmail.com<mailto:tompante...@gmail.com>] Sent: Friday, June 08, 2018 12:41 AM To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> Cc: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>; genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> Subject: Re: yang notifications to CDS to emit interesting state/status changes On Thu, Jun 7, 2018 at 3:05 PM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: [Changed subject] No, that’s not the point. I have event A that can be fired on nodeA, event B fired on node B, both are DTCNs but on different shard leaders. But I want both the events to be processed on same node. That's where EOS/cluster singleton come into play. With cluster singleton you spin up the DTCLs only when the node gets ownership. Thanks, Faseela From: Tom Pantelis [mailto:tompante...@gmail.com<mailto:tompante...@gmail.com>] Sent: Friday, June 08, 2018 12:32 AM To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> Cc: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>; controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>; genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> Subject: Re: [infrautils-dev] [controller-dev] OK to resurrect c/64522 to first move infrautils.DiagStatus integration for datastore from genius to controller, and then improve it for GENIUS-138 ? On Thu, Jun 7, 2018 at 2:49 PM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: Tom, Currently we have certain cases, where we use EOS to ensure that we process a set of northbound+southbound events on same node. (I am not sure whether that is the actual purpose of EOS, but we use it like that as well. ;)) This has certain issues that in a 3 node cluster, your entity owner might be node2, but the datastores you are writing to as a result of the event has a leader on node1, and the writes will end up being slow. So if I have a mechanism to force default-operational shard DTCNs to be processed on the leader of default-config-shard(if my writes as a result of the notifications is going to be config shard writes), I would like to use that.(I am not sure whether I made it clear, we can discuss this in our next genius meeting as well. I can point you to some usages in genius.) Thanks, Faseela You can use a DataTreeChangeListener rather than a ClusteredDataTreeChangeListener. The former is only notified on the shard leader and thus only one in the cluster. From: Tom Pantelis [mailto:tompante...@gmail.com<mailto:tompante...@gmail.com>] Sent: Friday, June 08, 2018 12:13 AM To: Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> Cc: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>>; infrautils-...@lists.opendaylight.org<mailto:infrautils-...@lists.opendaylight.org>; controller-dev <controller-dev@lists.opendaylight.org<mailto:controller-dev@lists.opendaylight.org>>; genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>; Robert Varga <n...@hq.sk<mailto:n...@hq.sk>> Subject: Re: [infrautils-dev] [controller-dev] OK to resurrect c/64522 to first move infrautils.DiagStatus integration for datastore from genius to controller, and then improve it for GENIUS-138 ? On Thu, Jun 7, 2018 at 2:39 PM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: Not related in this context, but if we can get shard leader change notification, can we use that to derive an entity owner instead of using EOS? ;) Not exactly sure what you mean but shards and EOS are 2 different concepts...
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
