Hi Ed - 

Thanks much for this.

A question that came up that I wanted to reflect over on list -- which component of the model driven SAL is intended to do reconciliation in the case where you have multiple running instances of a <provider,broker,application> that temporarily get out of sync?  I'm assuming the gist is to replay notifications, but is the design intent to do reconciliation of out-of-order notifications at the Application layer, or is the intent to handle this further down?  (Feel free to say "errr - call Colin and Jan for a walk-through of the basics" if I'm totally off track, or if this should be handled through some mechanism other than the SAL.)

(For context - several of the net-virt-platform components where we're scoping the porting effort follow a design pattern that makes specific assumptions about the way that the storage service reconciles under load and split-brain scenarios.  Think of physical placement of a controller per pod hanging off a DC spine, where each controller is master for one pod and the slave for another.)

-K

 

On Thu, May 16, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:

In the TSC call today I was asked to aggregate the information currently put out there about the

Model Driven SAL and send it out to discuss to draw greater attention to it.

The initial email (there are others in the list archives):

https://lists.opendaylight.org/pipermail/controller-dev/2013-April/000188.html

The top of the wiki page cluster around it:

https://wiki.opendaylight.org/view/OpenDaylight_Controller:Model-Driven_Controller_Service_Abstraction_Layer

Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev

--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss