Circling back to that model driven SAL thing
|
Ken Gray <kgray@...>
Forgive me if this was covered already ..
I was musing about the model driven SAL and all the offerings coming out … and wondering whether in the review process we're catching the commonalities between offerings (either existing overlap or potential future overlap) and in the spirit of a model-driven
SAL … pushing people to do their data model if they're breaking new ground and augment if they are just adding additional functionality.
I know it was discussed generally in the abstraction of say … the southbound plugins and how they bubble up their peculiarities to an application and reuse models/API for general functionality. Essentially, how to keep the API from exploding … That is to
say, ODP TSC needs to realize that it is tasking contributors with a fundamental abstraction that needs to be expanded in future. There's essentially two theaters for this – when you create a plugin (as we've informally discussed) and when you create some
sort of controller service element within the controller. In order to avoid rework, these fundamental abstractions need to be mapped right at base and be logically augmentable as scope of use expans ... for example, like we're doing in topology.
Looking at what is up for review (and not picking on anyone here, just picking a bit at my concern):
The Plexxi offering ... the real deal here is about policy service interface and analytics service interfaces (because Plexxi affinity can be set up through either ... analytics can trigger imbedded policies beyond a default or changes to user proscribed
policies based on the trigger .. in their product ...whether they do both as their "tuning" in the contribution is up to them, but they could end up with both interfaces), that's what they will be describing FUNDAMENTALLY. This manifests even in their own
drawings as a service layer function (rightfully, IMO).
Another example is the LISP overlay abstraction thing ... how does this differ from the NEC NVT thing such that they couldn't flesh out a common data model container? After all, it's all map abstraction
(loosely) …this is a double/triple case, one of the reuse of generic functions exposed by the SAL for SB protocols, another for the reuse of the flow management abstraction in the services layer and an overlap potential between the abstractions provided by
NVT and the LISP mapper . I know for the LISP SB, we may already have work on the mechanism driver to get this straight, but at what point does somebody say "hey, you have to check in whatever's common ..here …and whatever is unique …here"?
It's cool to say "not now because we don't know WHAT the service ultimately looks like enough to create a base model at this time" ... as long as we know that we may have to go back and rework.
The unfortunate side-effect being that the APIs for the applications might change.
Otherwise, we have a massively expanding API set.
Lots of questions, right? Some of this is just me catching up on process, so IF this is all fleshed out and everyone's comfy with the plan … just unicast me a response.
|
|
|
|
Chris Wright <chrisw@...>
* Ken Gray (kgray@...) wrote:
<snip the good questions> Lots of questions, right? Some of this is just me catching up on process, so IF this is all fleshed out and everyone's comfy with the plan … just unicast me a response.This is pretty much exactly why I was bringing up the API review in a thread a little while back. So yes, I think we need a better plan than what we have now. thanks, -chris |
|
|
|
Colin Dixon <ckd@...>
I see that this kind of got lost, but I think you make exactly the right points. So far, what we've done is to collect a bunch of pieces of code which have overlapping pieces, but we've only started the process of finding the overlaps combining them into a single, unified suite of features. |
|
|
|
Ken Gray <kgray@...>
Thanks, Colin. This is fine for now. I have to check my sanity and make sure I'm following the bouncing ball occasionally.
From: Colin Dixon <ckd@...>
Date: Thu, 5 Sep 2013 22:07:03 -0500 To: Ken Gray <kgray@...> Cc: "tsc@..." <tsc@...>, <tsc-bounces@...> Subject: Re: [OpenDaylight TSC] Circling back to that model driven SAL thing I see that this kind of got lost, but I think you make exactly the right points. So far, what we've done is to collect a bunch of pieces of code which have overlapping pieces, but we've only started the process of finding
the overlaps combining them into a single, unified suite of features. |
|
|