On Thu, Jun 7, 2018 at 3:38 PM, Faseela K <faseel...@ericsson.com> wrote:
> > > > > *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> > wrote: > > > > > > On Thu, Jun 7, 2018 at 3:20 PM, Faseela K <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. > > > That could get tricky - there may be issues with transitions and notification delays/timing where possibly no one processes an event at the time it's received. Also that seems like it would tie the code to a specific shard configuration which may not be desirable. Perhaps what you want is a DataBroker-like API that only performs the operation if the shard leader is local. So all nodes get a DTCN and commit a write operation but only one node actually executes it.
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
