I can think of one case which can fall-flat with the colocation of EOS owner of registered entity with a specific shard is that : When the entity owner starts running txns against another shard which may not be collocated, then we do not get the fullest benefit of colocation.
For example, we register entity with name “I_want_to_be_colocated_with_shard_A_leader” and we have a suitable owner selection strategy to oblige the requirement, above entity can get the fullest benefit of colocation when above entity owner only confines its interactions only with shard-A. If that is what we do for 80% of the functionality, then certainly such ownership-selection-strategy would yield good gains ESOS tries to keep itself agnostic to this by allowing extension of strategy to select the owner – there are few strategies already in place. https://github.com/opendaylight/controller/tree/master/opendaylight/md-sal/sal-distributed-datastore/src/main/java/org/opendaylight/controller/cluster/datastore/entityownership/selectionstrategy @Tom, Please correct me if I have missed something Regards Muthu From: controller-dev-boun...@lists.opendaylight.org [mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Faseela K Sent: Friday, June 08, 2018 12:19 AM To: Tom Pantelis <tompante...@gmail.com> Cc: infrautils-...@lists.opendaylight.org; controller-dev <controller-dev@lists.opendaylight.org>; genius-...@lists.opendaylight.org Subject: Re: [controller-dev] [infrautils-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 ? 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 From: Tom Pantelis [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... Thanks, Faseela From: infrautils-dev-boun...@lists.opendaylight.org<mailto:infrautils-dev-boun...@lists.opendaylight.org> [mailto:infrautils-dev-boun...@lists.opendaylight.org<mailto:infrautils-dev-boun...@lists.opendaylight.org>] On Behalf Of Tom Pantelis Sent: Friday, June 08, 2018 12:07 AM To: Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>> Cc: 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 1:14 PM, Michael Vorburger <vorbur...@redhat.com<mailto:vorbur...@redhat.com>> wrote: Robert, just to avoid any misunderstandings and unnecessary extra work to throw away, may we double check and confirm that we correctly understand your comment in https://jira.opendaylight.org/browse/GENIUS-138 to mean that we are past the "dependency of a mature project on an incubation project" objection and you are now OK with that we resurrect https://git.opendaylight.org/gerrit/#/c/64522/, to first move infrautils.DiagStatus integration for datastore from genius to controller? We would then improve it, in controller instead of genius, for the improvement proposed in issue GENIUS-138. Tom, OK for you as well to have such a dependency from controller to infrautils? I don't have a problem with it. BTW - I'm planning to add yang notifications to CDS to emit interesting state/status changes, eg akka member sate changes (Up, Down, Unreachable etc), shard leader/role changes .... Tx, M. -- Michael Vorburger, Red Hat vorbur...@redhat.com<mailto:vorbur...@redhat.com> | IRC: vorburger @freenode | ~ = http://vorburger.ch<http://vorburger.ch/> _______________________________________________ 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
