Operating System: All
Platform: All

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.

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.

Regards,

J. Greg Hall

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.

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..

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.

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.

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?

As background, in SFC we rely on having this behavior.

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.