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 ?

2018-06-08 Thread Anil Vishnoi
On Fri, Jun 8, 2018 at 4:50 PM, Faseela K wrote: > > > > > *From:* Tom Pantelis [mailto:tompante...@gmail.com] > *Sent:* Saturday, June 09, 2018 2:24 AM > *To:* Anil Vishnoi > *Cc:* Faseela K ; Michael Vorburger < > vorbur...@redhat.com>; infrautils-...@lists.opendaylight.org; > controller-dev

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 ?

2018-06-08 Thread Anil Vishnoi
On Thu, Jun 7, 2018 at 11:39 AM, Faseela K 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? ;) > ​Humble suggestion, don't use shard location/ownership status in your business logic ;-)​

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 ?

2018-06-07 Thread Muthukumaran K
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

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 ?

2018-06-07 Thread Faseela K
Btw, I don’t want to divert the topic. ☺ The discussion here was whether it is now OK to resurrect https://git.opendaylight.org/gerrit/#/c/64522/, to first move infrautils.DiagStatus integration for datastore from genius to controller? Thanks, Faseela From:

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 ?

2018-06-07 Thread Tom Pantelis
On Thu, Jun 7, 2018 at 2:49 PM, Faseela K 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. ;)) >

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 ?

2018-06-07 Thread Faseela K
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

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 ?

2018-06-07 Thread Tom Pantelis
On Thu, Jun 7, 2018 at 2:39 PM, Faseela K 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... > > >

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 ?

2018-06-07 Thread Faseela K
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? ;) Thanks, Faseela From: infrautils-dev-boun...@lists.opendaylight.org [mailto:infrautils-dev-boun...@lists.opendaylight.org] On Behalf Of Tom