https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-916 controller <p>When an application is deployed on every node in a cluster it may have different requirements as to which instance of the application should receive the notification. In Helium the default was to deliver the notification to a local listener.</p> <p>The enhancement that is needed is to do the following types of notifications,</p> <ul class="alternate" type="square"> <li>NotifyAll</li> <li>NotifyLocal</li> <li>NotifyAtleastOne</li> <li>NotifyAtMostOne</li> <li>And anything else I cannot think of today</li> </ul> <p>A rough consensus on design is that this could be achieved by creating a subclass per listener where the listener provides additional information about how the notification should happen. This subclassed listener should be available on both the Binding Aware and Binding Independent interfaces of MD-SAL and should be available for both YANG and DataChange notifications.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-916

Clustering : Provide a mechanism for consumers to specify how they would like to receive notifications in a cluster

Bug Resolved Done Unassigned Moiz Raja Thu, 2 Oct 2014 20:57:43 +0000 Thu, 19 Oct 2017 21:26:43 +0000 Thu, 4 Feb 2016 13:48:27 +0000 Helium clustering 0 7 <p>I’d like to promote the simplest system (programming model) possible with respect to clustering, as even a simple clustering system is complex for mere mortals. Anyone product managing ODL will tell you that if you want lots of user of your system, and you do!, it’s gotta be consumable by mere mortals.</p> <p>I would ask why it seems necessary to use notifications to replicate stats to an external database instead of treating the external database as a cluster itself using it’s own replication. You don’t want a near-realtime system bogged down with historical workloads. Let the NotifiyOne be the only mechanism in the near-realtime system, ( I think we have our hands fully just getting this to work in all cluster failure/recovery modes ), and pump those stats to an external historical repository which can keep itself simple for it’s own purposes.</p> <p>Regards,</p> <p>J. Greg Hall</p> <p>Moiz I completely agree, however would it make sense to first divide the clustering zones. What I mean by that is in most deployments I've been planning that includes clustering a requirement is for things to propagate both at a group-level and others at a zone level. This affects how things are sharded but also would affect the notification radius. For example, when using a set of OF switches in a clustered controller environment many will want to have X instances managing a specific group of switch and applications but will still want to make sure they can get the global views / behaviors from a logically centralized controller. </p> <p>I know this is a bit out of scope for this discussion but I see a relationship between notifications, ActorRefs and notification. I think what you suggested is a good first step for the notifs but what I am getting to is that there is a need for a nuance between local and "global world" that is required as well..</p> <p>This looks like the notification publisher specifies the notification scope. I do not believe that is correct, as it implies the publisher knows where the consumers are.</p> <p>I would propose to go the other way around, where the subscribers specify the distance how far their subscription is effective: Local, Cluster, Global. The reason for this is, typically, that we tend to attach protocol conversion into SAL, which can also forward requests to subscribe.</p> <p>Does this apply to DataChangeListeners as well? Meaning if a a provider writes to the datastore, will all listeners across all ODL clustered nodes get a OnDataChanged() callback?</p> <p>As background, in SFC we rely on having this behavior.</p> <p>A while back, we implemented data change notifications on every cluster node via a specific listener interface. Along with the EntityOwnershipService this has satisfied current requirements for cluster-aware consumers. We can create new bugs if further requirements/enhancements are needed in the future.</p> Blocks CONTROLLER-917 Development External issue ID 2139 External issue URL Issue Type ODL SR Target Milestone Rank 0|i02ncn: