|
I think that there's been some confusion because there are two different things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in the org.opendaylight.controller.sal.implementation.internal package/bundle. The idea is for it to provide the key services which all other applications are based on. I think that it is exactly supposed to do what principle #3 says and provide a single northbound interface to multiple southbound protocols.
The second thing is the YANG-based model-driven SAL presented yesterday. The model-driven SAL is about having a single, declarative specification for a set of APIs and then generating the bindings to access those APIs in a variety of different languages and environments. One obviously candidate set of APIs would be the actual SAL in the code today.
Hopefully this clarifies some things and others can jump in to add more information.
--Colin -----controller-dev-bounces@... wrote: -----To: discuss@..., controller-dev@... From: David Lenrow Sent by: controller-dev-bounces@... Date: 04/30/2013 04:20PM Subject: [controller-dev] Does SAL proposal satisfy arch principal #3? Hi folks. Maybe I'm missing something but based on the discussion on yesterdays call, it seems like the SAL proposed does not satisfy architectural principal #3: "Service Abstraction Layer (SAL): Where possible, allow for multiple southbound protocols to present the same northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a service/application once and expect to get interoperability with all of the southbound drivers/plugins current and future. Doesn't sound like this would result from what is proposed, and I'm not ready to accept that as impossible. The notion that one could close this gap with per-SBI translators appears to miss the point of the exercise. Can someone point out what I've missed? If I understood correctly, I would expect many of you to push back and seek something that better meets the stated arch principal. Do we have the wrong goal or the wrong solution?
-- Cheers, -drl ---------------------- Dave Lenrow Director, Partner Ecosystem Plexxi 617 329 1861
|
|
|
Thomas Nadeau <tnadeau@...>
I think that there's been some confusion because there are two different things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in the org.opendaylight.controller.sal.implementation.internal package/bundle. The idea is for it to provide the key services which all other applications are based on. I think that it is exactly
supposed to do what principle #3 says and provide a single northbound interface to multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday. The model-driven SAL is about having a single, declarative specification for a set of APIs and then generating the bindings to access those APIs in a variety of different languages
and environments. One obviously candidate set of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven approach IMHO, but we need to see some code in action to verify this works. I missed the presentation, but as I understand
it, the tools necessary to achieve the code-generation from the model will be made available soon. Is that correct?
--Tom
Hopefully this clarifies some things and others can jump in to add more information.
--Colin
-----controller-dev-bounces@... wrote: -----
To:
discuss@...,
controller-dev@...
From: David Lenrow
Sent by: controller-dev-bounces@...
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on yesterdays call, it seems like the SAL proposed does not satisfy architectural principal #3:
"Service Abstraction Layer (SAL): Where possible, allow for multiple southbound protocols to present
the same northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a service/application once and expect to get interoperability with all of the southbound drivers/plugins current
and future. Doesn't sound like this would result from what is proposed, and I'm not ready to accept that as impossible. The notion that one could close this gap with per-SBI translators appears to miss the point of the exercise. Can someone point out what
I've missed? If I understood correctly, I would expect many of you to push back and seek something that better meets the stated arch principal. Do we have the wrong goal or the wrong solution?
--
Cheers,
-drl
----------------------
Dave Lenrow
Director, Partner Ecosystem
Plexxi
617 329 1861
|
|
|
It's my understanding that the majority of the code generation tools are already in the repo now. I just haven't had time to check them out yet. I'm sticking in mail from Tony below that gives some high-level instructions and a tutorial/demo to walk through.
--Colin -----Forwarded by Colin Dixon/Austin/IBM on 05/01/2013 09:04AM -----To: Colin Dixon/Austin/IBM@IBMUS From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...> Date: 04/23/2013 12:23PM Cc: "controller-dev@..." <controller-dev@...>, "controller-dev-bounces@..." <controller-dev-bounces@...> Subject: RE: [controller-dev] Model-Driven Approach to SAL
toggle quoted messageShow quoted text
From: Colin Dixon [mailto:ckd@...]
Sent: Monday, April 22, 2013 11:01 PM
To: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
Cc: controller-dev@...; controller-dev-bounces@...
Subject: Re: [controller-dev] Model-Driven Approach to SAL Hey Tony,
After seeing this at the Hackfest, I'm vaguely familiar with the high-level idea, but there's a lot of code running about in that subdirectory and it's not terribly obviously how you can stitch it together to do useful things.
If it was possible to have a quick tutorial to show how to start with a basic model in Yang and then compile that to the right language-specific interfaces and then build out from there, that would be great. I think that the code to do this might already even be in the git repository and it would really just be a matter of having a quick wiki page that pointed at the right files and commands to look at and run.
Thanks!
--Colin
controller-dev-bounces@... wrote on 04/17/2013 06:33:57 PM:
> From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at
> Cisco)" <ttkacik@...>
> To: "controller-dev@..." <controller-
> dev@...>
> Date: 04/17/2013 06:34 PM
> Subject: [controller-dev] Model-Driven Approach to SAL
> Sent by: controller-dev-bounces@...
>
> Hi all,
> we are exploring and prototyping new approach to implement Service
> Abstraction Layer in controller and want to use model-driven
> approach to modeling services and data in controller.
>
> The model-driven approach is based on YANG schemas which will model
> data, notifications and procedure calls provided by controller components.
>
> The model-driven approach will enable the following:
> - Decoupling implementation and API
> - automated CLI generation
> - automated REST API generation & documentation (XML or JSON based)
> - Data Validators
>
> To ease development of controller plugins / components we are
> developing following infrastructure components and functionality:
>
> - YANG Parser
> - Programmatic API generation from YANG schema
> - Programmatic APIs could be consumed by north-bound Java Applications
> - South-bound plugins will implement generated API contracts
> - YANG Maven plugin for processing YANG schemas and generation
> of source code and/or resources, with plugable architecture, which
> will enable addition of different outputs / API mappings
>
> The documentation for the effort is located at:
> https://wiki.opendaylight.org/view/OpenDaylight_Controller:Model-
> Driven_Controller_Service_Abstraction_Layer
>
> The code base for ongoing effort is located in controller.git in /
> opendaylight/sal/yang-prototype.
>
> We would like to hear your input and thoughts on model-driven
> approach or code.
>
> Regards,
> Tony Tkacik
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev -----Thomas Nadeau <tnadeau@...> wrote: -----To: Colin Dixon/Austin/IBM@IBMUS, David Lenrow <david.lenrow@...> From: Thomas Nadeau <tnadeau@...> Date: 05/01/2013 06:42AM Cc: "discuss@..." <discuss@...>, "controller-dev@..." <controller-dev@...> Subject: Re: [OpenDaylight Discuss] [controller-dev] Does SAL proposal satisfy arch principal #3?
I think that there's been some confusion because there are two different things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in the org.opendaylight.controller.sal.implementation.internal package/bundle. The idea is for it to provide the key services which all other applications are based on. I think that it is exactly
supposed to do what principle #3 says and provide a single northbound interface to multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday. The model-driven SAL is about having a single, declarative specification for a set of APIs and then generating the bindings to access those APIs in a variety of different languages
and environments. One obviously candidate set of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven approach IMHO, but we need to see some code in action to verify this works. I missed the presentation, but as I understand
it, the tools necessary to achieve the code-generation from the model will be made available soon. Is that correct?
--Tom
Hopefully this clarifies some things and others can jump in to add more information.
--Colin
-----controller-dev-bounces@... wrote: -----
To:
discuss@...,
controller-dev@...
From: David Lenrow
Sent by: controller-dev-bounces@...
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on yesterdays call, it seems like the SAL proposed does not satisfy architectural principal #3:
"Service Abstraction Layer (SAL): Where possible, allow for multiple southbound protocols to present
the same northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a service/application once and expect to get interoperability with all of the southbound drivers/plugins current
and future. Doesn't sound like this would result from what is proposed, and I'm not ready to accept that as impossible. The notion that one could close this gap with per-SBI translators appears to miss the point of the exercise. Can someone point out what
I've missed? If I understood correctly, I would expect many of you to push back and seek something that better meets the stated arch principal. Do we have the wrong goal or the wrong solution?
--
Cheers,
-drl
----------------------
Dave Lenrow
Director, Partner Ecosystem
Plexxi
617 329 1861
|
|
|
Thomas Nadeau <tnadeau@...>
Cool. Will check them out.
--Tom
toggle quoted messageShow quoted text
It's my understanding that the majority of the code generation tools are already in the repo now. I just haven't had time to check them out yet. I'm sticking in mail from Tony
below that gives some high-level instructions and a tutorial/demo to walk through.
--Colin
-----Forwarded by Colin Dixon/Austin/IBM on 05/01/2013 09:04AM -----
To: Colin Dixon/Austin/IBM@IBMUS
From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" < ttkacik@...>
Date: 04/23/2013 12:23PM
Cc: " controller-dev@..." < controller-dev@...>, " controller-dev-bounces@..."
< controller-dev-bounces@...>
Subject: RE: [controller-dev] Model-Driven Approach to SAL
Hi Colin,
I put up a little tutorial to build and run the demo from Hackfest by yourself.
You could find it at https://wiki.opendaylight.org/view/OpenDaylight_Controller:MDA_YANG_Demo
The basic structure of code base is documented here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MDA_YANG_Code_Organization
All mentioned components are maven artifacts.
I plan to continuosly add more documentation and samples on the matter as we will continue with the development, for now more resources on YANG
could be find at:
http://www.yang-central.org/ and http://www.netconfcentral.org/
Tony
Hey Tony,
After seeing this at the Hackfest, I'm vaguely familiar with the high-level idea, but there's a lot of code running about in that subdirectory and it's not terribly obviously how you can stitch
it together to do useful things.
If it was possible to have a quick tutorial to show how to start with a basic model in Yang and then compile that to the right language-specific interfaces and then build out from there, that would
be great. I think that the code to do this might already even be in the git repository and it would really just be a matter of having a quick wiki page that pointed at the right files and commands to look at and run.
Thanks!
--Colin
controller-dev-bounces@... wrote on 04/17/2013 06:33:57 PM:
> From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at
> Cisco)" <ttkacik@...>
> To: "controller-dev@..." <controller-
> dev@...>
> Date: 04/17/2013 06:34 PM
> Subject: [controller-dev] Model-Driven Approach to SAL
> Sent by: controller-dev-bounces@...
>
> Hi all,
> we are exploring and prototyping new approach to implement Service
> Abstraction Layer in controller and want to use model-driven
> approach to modeling services and data in controller.
>
> The model-driven approach is based on YANG schemas which will model
> data, notifications and procedure calls provided by controller components.
>
> The model-driven approach will enable the following:
> - Decoupling implementation and API
> - automated CLI generation
> - automated REST API generation & documentation (XML or JSON based)
> - Data Validators
>
> To ease development of controller plugins / components we are
> developing following infrastructure components and functionality:
>
> - YANG Parser
> - Programmatic API generation from YANG schema
> - Programmatic APIs could be consumed by north-bound Java Applications
> - South-bound plugins will implement generated API contracts
> - YANG Maven plugin for processing YANG schemas and generation
> of source code and/or resources, with plugable architecture, which
> will enable addition of different outputs / API mappings
>
> The documentation for the effort is located at:
> https://wiki.opendaylight.org/view/OpenDaylight_Controller:Model-
> Driven_Controller_Service_Abstraction_Layer
>
> The code base for ongoing effort is located in controller.git in /
> opendaylight/sal/yang-prototype.
>
> We would like to hear your input and thoughts on model-driven
> approach or code.
>
> Regards,
> Tony Tkacik
> _______________________________________________
> controller-dev mailing list
> controller-dev@...
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
-----Thomas Nadeau <tnadeau@...> wrote: -----
To: Colin Dixon/Austin/IBM@IBMUS, David Lenrow < david.lenrow@...>
From: Thomas Nadeau < tnadeau@...>
Date: 05/01/2013 06:42AM
Cc: " discuss@..." < discuss@...>, " controller-dev@..."
< controller-dev@...>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Does SAL proposal satisfy arch principal #3?
I think that there's been some confusion because there are two different things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in the org.opendaylight.controller.sal.implementation.internal package/bundle. The idea is for it to provide the key services which all other applications are based on. I think that it is exactly
supposed to do what principle #3 says and provide a single northbound interface to multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday. The model-driven SAL is about having a single, declarative specification for a set of APIs and then generating the bindings to access those APIs in a variety of different languages
and environments. One obviously candidate set of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven approach IMHO, but we need to see some code in action to verify this works. I missed the presentation, but as I understand
it, the tools necessary to achieve the code-generation from the model will be made available soon. Is that correct?
--Tom
Hopefully this clarifies some things and others can jump in to add more information.
--Colin
-----controller-dev-bounces@... wrote: -----
To:
discuss@...,
controller-dev@...
From: David Lenrow
Sent by: controller-dev-bounces@...
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on yesterdays call, it seems like the SAL proposed does not satisfy architectural principal #3:
"Service Abstraction Layer (SAL): Where possible, allow for multiple southbound protocols to present
the same northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a service/application once and expect to get interoperability with all of the southbound drivers/plugins current
and future. Doesn't sound like this would result from what is proposed, and I'm not ready to accept that as impossible. The notion that one could close this gap with per-SBI translators appears to miss the point of the exercise. Can someone point out what
I've missed? If I understood correctly, I would expect many of you to push back and seek something that better meets the stated arch principal. Do we have the wrong goal or the wrong solution?
--
Cheers,
-drl
----------------------
Dave Lenrow
Director, Partner Ecosystem
Plexxi
617 329 1861
|
|
|
David Lenrow <david.lenrow@...>
Hi Tom, The discussion on the call related to the proposed model based system caused me this confusion. I really like the approach to defining and generating code that was presented. After hearing a description of a capability to allow new per-module API extensions to be installed when a module loads, Rob asked (paraphrasing) doesn't this result in problems because the resulting APIs toward the upper layers would not be consistent/unified across plugin implementations (Principal #3)? The answer was that translators could be developed from the just-loaded non-standard API to something common that would be presented upward. I would have asked for clarification on the call, but was in a bad spot on a mobile phone at the time.
Are folks suggesting that there will be two co-resident interfaces (both being called the SAL at present) with a model based, run-time extensible lower layer and a uniform/unified upper layer? How would features never anticipated in the upper layer, yet exposed by the lower, be accessed? Have we gone in a circle?
Is the goal to allow both generic and custom APIs to be accessible from the service/app layer? This would allow a service/app to utilize any/all plugins using the set of common abstractions. It would also allow coordinated loading of both a plugin with unique API features and a tightly coupled service/app that would do "special stuff" with unique awareness of features and API client code aligned with the custom APIs exposed.
The buffet of SDN technology provided by the two controller/platform submissions has exciting possibilities and I'm trying to understand the many choices. If this is all explained somewhere please send links to docs. I just saw links to some tools/code from tony (CC'ed) and I'll go look. Maybe tony could help clarify subjects above by commenting on this thread?
Creating a unified plugin API that abstracts SBI so one can develop services that don't care which device interface loads is a problem I have not yet seen solved well. I'm hoping we can collectively make ODP the place where we nail it so innovation can proliferate in the upper layers of the SDN stack.
On Wed, May 1, 2013 at 7:37 AM, Thomas Nadeau <tnadeau@...> wrote:
I think that there's been some confusion because there are two different things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in the org.opendaylight.controller.sal.implementation.internal package/bundle. The idea is for it to provide the key services which all other applications are based on. I think that it is exactly
supposed to do what principle #3 says and provide a single northbound interface to multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday. The model-driven SAL is about having a single, declarative specification for a set of APIs and then generating the bindings to access those APIs in a variety of different languages
and environments. One obviously candidate set of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven approach IMHO, but we need to see some code in action to verify this works. I missed the presentation, but as I understand
it, the tools necessary to achieve the code-generation from the model will be made available soon. Is that correct?
--Tom
Hopefully this clarifies some things and others can jump in to add more information.
--Colin
-----controller-dev-bounces@... wrote: -----
To:
discuss@...,
controller-dev@...
From: David Lenrow
Sent by: controller-dev-bounces@...
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on yesterdays call, it seems like the SAL proposed does not satisfy architectural principal #3:
"Service Abstraction Layer (SAL): Where possible, allow for multiple southbound protocols to present
the same northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a service/application once and expect to get interoperability with all of the southbound drivers/plugins current
and future. Doesn't sound like this would result from what is proposed, and I'm not ready to accept that as impossible. The notion that one could close this gap with per-SBI translators appears to miss the point of the exercise. Can someone point out what
I've missed? If I understood correctly, I would expect many of you to push back and seek something that better meets the stated arch principal. Do we have the wrong goal or the wrong solution?
--
Cheers,
-drl
----------------------
Dave Lenrow
Director, Partner Ecosystem
Plexxi
-- Cheers, -drl ---------------------- Dave Lenrow Director, Partner Ecosystem Plexxi 617 329 1861
|
|
|
Hi Colin,
the code in the repository is yet not enough to get to the goal, but we are committing code to get to that level so to make concrete Tony and Jan's presentation delivered on Monday.
Thanks,
Giovanni
toggle quoted messageShow quoted text
On 01-May-13 16:05, Colin Dixon wrote: It's my understanding that the majority of the code generation tools are already
in the repo now. I just haven't had time to check them out yet. I'm sticking in
mail from Tony below that gives some high-level instructions and a tutorial/demo
to walk through.
--Colin
-----Forwarded by Colin Dixon/Austin/IBM on 05/01/2013 09:04AM -----
To: Colin Dixon/Austin/IBM@IBMUS
From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)"
<ttkacik@...>
Date: 04/23/2013 12:23PM
Cc: "controller-dev@..."
<controller-dev@...>,
"controller-dev-bounces@..."
<controller-dev-bounces@...>
Subject: RE: [controller-dev] Model-Driven Approach to SAL
Hi Colin,
I put up a little tutorial to build and run the demo from Hackfest by yourself.
You could find it at
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MDA_YANG_Demo
The basic structure of code base is documented here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:MDA_YANG_Code_Organization
All mentioned components are maven artifacts.
I plan to continuosly add more documentation and samples on the matter as we
will continue with the development, for now more resources on YANG
could be find at:
http://www.yang-central.org/ and http://www.netconfcentral.org/
Tony
*From:* Colin Dixon [mailto:ckd@...]
*Sent:* Monday, April 22, 2013 11:01 PM
*To:* Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
*Cc:* controller-dev@...;
controller-dev-bounces@...
*Subject:* Re: [controller-dev] Model-Driven Approach to SAL
Hey Tony,
After seeing this at the Hackfest, I'm vaguely familiar with the high-level
idea, but there's a lot of code running about in that subdirectory and it's not
terribly obviously how you can stitch it together to do useful things.
If it was possible to have a quick tutorial to show how to start with a basic
model in Yang and then compile that to the right language-specific interfaces
and then build out from there, that would be great. I think that the code to do
this might already even be in the git repository and it would really just be a
matter of having a quick wiki page that pointed at the right files and commands
to look at and run.
Thanks!
--Colin
controller-dev-bounces@...
<mailto:controller-dev-bounces@...> wrote on 04/17/2013
06:33:57 PM:
From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at
Cisco)" <ttkacik@... <mailto:ttkacik@...>>
To: "controller-dev@... <mailto:controller-dev@...>" <controller-
dev@... <mailto:dev@...>>
Date: 04/17/2013 06:34 PM
Subject: [controller-dev] Model-Driven Approach to SAL
Sent by:controller-dev-bounces@... <mailto:controller-dev-bounces@...>
Hi all,
we are exploring and prototyping new approach to implement Service
Abstraction Layer in controller and want to use model-driven
approach to modeling services and data in controller.
The model-driven approach is based on YANG schemas which will model
data, notifications and procedure calls provided by controller components.
The model-driven approach will enable the following:
- Decoupling implementation and API
- automated CLI generation
- automated REST API generation & documentation (XML or JSON based)
- Data Validators
To ease development of controller plugins / components we are
developing following infrastructure components and functionality:
- YANG Parser
- Programmatic API generation from YANG schema
- Programmatic APIs could be consumed by north-bound Java Applications
- South-bound plugins will implement generated API contracts
- YANG Maven plugin for processing YANG schemas and generation
of source code and/or resources, with plugable architecture, which
will enable addition of different outputs / API mappings
The documentation for the effort is located at:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Model-
Driven_Controller_Service_Abstraction_Layer
The code base for ongoing effort is located in controller.git in /
opendaylight/sal/yang-prototype.
We would like to hear your input and thoughts on model-driven
approach or code.
Regards,
Tony Tkacik
_______________________________________________
controller-dev mailing list
controller-dev@... <mailto:controller-dev@...>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
-----Thomas Nadeau <tnadeau@...> wrote: -----
To: Colin Dixon/Austin/IBM@IBMUS, David Lenrow <david.lenrow@...>
From: Thomas Nadeau <tnadeau@...>
Date: 05/01/2013 06:42AM
Cc: "discuss@..." <discuss@...>,
"controller-dev@..." <controller-dev@...>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Does SAL proposal satisfy
arch principal #3?
From: Colin Dixon <ckd@... <mailto:ckd@...>>
Date: Wednesday, May 1, 2013 12:02 AM
To: David Lenrow <david.lenrow@... <mailto:david.lenrow@...>>
Cc: "discuss@... <mailto:discuss@...>"
<discuss@... <mailto:discuss@...>>,
"controller-dev@...
<mailto:controller-dev@...>"
<controller-dev@...
<mailto:controller-dev@...>>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Does SAL proposal satisfy
arch principal #3?
I think that there's been some confusion because there are two different
things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in
the org.opendaylight.controller.sal.implementation.internal package/bundle.
The idea is for it to provide the key services which all other applications
are based on. I think that it is exactly supposed to do what principle #3
says and provide a single northbound interface to multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday. The
model-driven SAL is about having a single, declarative specification for a
set of APIs and then generating the bindings to access those APIs in a
variety of different languages and environments. One obviously candidate set
of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven approach
IMHO, but we need to see some code in action to verify this works. I missed the
presentation, but as I understand it, the tools necessary to achieve the
code-generation from the model will be made available soon. Is that correct?
--Tom
Hopefully this clarifies some things and others can jump in to add more
information.
--Colin
-----controller-dev-bounces@...
<mailto:-----controller-dev-bounces@...> wrote: -----
To: discuss@... <mailto:discuss@...>,
controller-dev@...
<mailto:controller-dev@...>
From: David Lenrow
Sent by: controller-dev-bounces@...
<mailto:controller-dev-bounces@...>
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on
yesterdays call, it seems like the SAL proposed does not satisfy
architectural principal #3: "*Service Abstraction Layer (SAL)*: Where
possible, allow for multiple southbound protocols to present the same
northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a
service/application once and expect to get interoperability with all of the
southbound drivers/plugins current and future. Doesn't sound like this
would result from what is proposed, and I'm not ready to accept that as
impossible. The notion that one could close this gap with per-SBI
translators appears to miss the point of the exercise. Can someone point
out what I've missed? If I understood correctly, I would expect many of you
to push back and seek something that better meets the stated arch principal.
Do we have the wrong goal or the wrong solution?
--
Cheers,
-drl
----------------------
*Dave Lenrow*
*Director, Partner Ecosystem*
*Plexxi*
*617 329 1861 *
_______________________________________________
controller-dev mailing list
controller-dev@...
<mailto:controller-dev@...>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
|
|
|
Hi David, let me try to address some of your doubts: On 01-May-13 18:45, David Lenrow wrote: Hi Tom,
The discussion on the call related to the proposed model based system caused me
this confusion. I really like the approach to defining and generating code that
was presented. After hearing a description of a capability to allow new
per-module API extensions to be installed when a module loads, Rob asked
(paraphrasing) doesn't this result in problems because the resulting APIs toward
the upper layers would not be consistent/unified across plugin implementations
(Principal #3)? The answer was that translators could be developed from the
just-loaded non-standard API to something common that would be presented upward.
I would have asked for clarification on the call, but was in a bad spot on a
mobile phone at the time.
Are folks suggesting that there will be two co-resident interfaces (both being
called the SAL at present) with a model based, run-time extensible lower layer
and a uniform/unified upper layer? How would features never anticipated in the
upper layer, yet exposed by the lower, be accessed? Have we gone in a circle? As Colin pointed out there are two things that are called SAL, and apologize for that confusion in effect we have the: - SAL: Service Abstraction Layer - Model Driven SAL The first one is the one existing infrastructure defined as a contract under directory opendaylight/sal/api. This defines a set of Java interfaces with supporting objects which are supposed to be the services that an application sitting on top of SAL expect from a protocol plugin and a protocol plugin would invoke toward the application. The interfaces are registered in the OSGi service registry and so the services can be injected in the system when a new plugin appear and can disappear when the plugin is removed. The second one is the abstraction layer defined by mean of YANG, this is work in progress. The first one will gradually move to the second one, by mean of replacing the current SAL service definition from Java to a Yang quasi-equivalent model and then let the Yang tool to generate the necessary Java code. Once the result is satisfactory the modeling of the contract will be only done in Yang. The side effect is that Yang model instead to be only written in the bundles part of the distribution can be loaded at runtime from protocols plugins for example implementing netconf or i2rs or any protocol that may be able to supplement yang augmentation to the base model written in the controller. Now let me speak about the case of what we have now in the system and lets park for a moment the model driven approach, so to have a sense of what you can do today and you can try at home. Lets say you are creating a protocol plugin Foo which is exposing a new service that is not yet defined by SAL and is not yet considered by any upper layer application, which i think is your concern. So the story would go like this: 1) The protocol plugin developer looked at the catalog of the existing functionality (right now we have topology, data packets, inventory, flow programmer, HW read services) and figure out that there is not a way for her/him to get information on what node to connect. The protocol plugin developer than can define a new service let say called "Resource" and define the interface by which the protocol plugin should get notified of the IP to which to connect in order to start talking the protocol implemented. This interface could be either implemented directly into SAL.API bundle or let say someone wants to keep the interface for it's use so it can decide to create a bundle with the API definition called "sal.resource.api" where it just define the contract to which the protocol plugin should adhere as well the app. Now lets say this interface even if not contributed can satisfy multiple node type so a "sal.resource.impl" bundle need to be implemented to route the messages toward the correct Node. 2) The protocol plugin developer now it has a service it can implement because there is the contract defined in "sal.resource.api", it implements the interface and then export the service in the OSGi service registry. Well everyone is happy, but of course the protocol plugin never get invoked because there is no one calling the Resource service. 3.1) Someone integrating the controller for a customer realize ehi i have the implementation of the protocol plugin Foo but it's useless without the Resource service being called. It them implement an application which expose some REST api or a gui element that can read the IP of the nodes to connect too, so to start the protocol and then call the Resource service if present in the OSGi service registry. Now the protocol plugin Foo can get to work. 3.2) A variation on 3.1 someone integrating the controller realize that the application calling the Resource service is really lame, it just provide a new version and forget about the bundle with the lame implementation. With this workflow i just wanted to show that there is no circle to break because if there is a never anticipated feature, first of all need to be defined someway, today by defining a java contract, then someone will implemented the provider and someone else can implement the consumer. Those entities don't need to be the same and there is no need to do at the same time. This is achieved thanks to the OSGi framework and the service dependency management, in fact it's very simple in OSGi to install consumer bundles without a provider in fact each bundle carries the dependency information in it and if those are not satisfied then simply the framework doesn't start the bundles that have unresolved dependency. The advantage of this modular approach is that encourage contract definition and then decouple producer consumer implementation. This is very popular in Java. Is the goal to allow both generic and custom APIs to be accessible from the
service/app layer? This would allow a service/app to utilize any/all plugins
using the set of common abstractions. It would also allow coordinated loading of
both a plugin with unique API features and a tightly coupled service/app that
would do "special stuff" with unique awareness of features and API client code
aligned with the custom APIs exposed. Yes, the reality is that we cannot uniform all the southbound to look the same else why some many variations, yet instead of having the applications to think in terms of specific southbound let say OF we want the applications on top of SAL to think in terms of services that can be provided by multiple southbound. Let pick for example data packet service, there are southbound protocol like openflow that provide it, but a BGP-LS/PCEP node won't be. Yet instead to create an application that process a certain kind of data packet assuming to work only on nodes that are OpenFlow, you can create that to say i depend on datapacket service and i expect the datapacket coming from network element to be DHCP packet. Such application will be able to work on any southbound protocol plugin that export data packet service. Hope this make more clear and not more confusing :) The buffet of SDN technology provided by the two controller/platform submissions
has exciting possibilities and I'm trying to understand the many choices. If
this is all explained somewhere please send links to docs. I just saw links to
some tools/code from tony (CC'ed) and I'll go look. Maybe tony could help
clarify subjects above by commenting on this thread?
Creating a unified plugin API that abstracts SBI so one can develop services
that don't care which device interface loads is a problem I have not yet seen
solved well. I'm hoping we can collectively make ODP the place where we nail it
so innovation can proliferate in the upper layers of the SDN stack.
In fact, we are not trying to find the holy grail, but are trying to abstract commonalities from concrete example and try to use them in network that have heterogeneous nodes, which is usually the case of a traditional network and will most likely be the case of an SDN network. Unfortunately one size fit all is not a reality in networking. Thanks, Giovanni
On Wed, May 1, 2013 at 7:37 AM, Thomas Nadeau <tnadeau@...
<mailto:tnadeau@...>> wrote:
From: Colin Dixon <ckd@... <mailto:ckd@...>>
Date: Wednesday, May 1, 2013 12:02 AM
To: David Lenrow <david.lenrow@... <mailto:david.lenrow@...>>
Cc: "discuss@... <mailto:discuss@...>"
<discuss@... <mailto:discuss@...>>,
"controller-dev@...
<mailto:controller-dev@...>"
<controller-dev@...
<mailto:controller-dev@...>>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Does SAL proposal
satisfy arch principal #3?
I think that there's been some confusion because there are two different
things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in
the org.opendaylight.controller.sal.implementation.internal
package/bundle. The idea is for it to provide the key services which all
other applications are based on. I think that it is exactly supposed to
do what principle #3 says and provide a single northbound interface to
multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday.
The model-driven SAL is about having a single, declarative specification
for a set of APIs and then generating the bindings to access those APIs
in a variety of different languages and environments. One obviously
candidate set of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven
approach IMHO, but we need to see some code in action to verify this works.
I missed the presentation, but as I understand it, the tools necessary to
achieve the code-generation from the model will be made available soon. Is
that correct?
--Tom
Hopefully this clarifies some things and others can jump in to add more
information.
--Colin
-----controller-dev-bounces@...
<mailto:-----controller-dev-bounces@...> wrote: -----
To: discuss@...
<mailto:discuss@...>,
controller-dev@...
<mailto:controller-dev@...>
From: David Lenrow __
Sent by: controller-dev-bounces@...
<mailto:controller-dev-bounces@...>
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on
yesterdays call, it seems like the SAL proposed does not satisfy
architectural principal #3: "*Service Abstraction Layer (SAL)*: Where
possible, allow for multiple southbound protocols to present the same
northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a
service/application once and expect to get interoperability with all of
the southbound drivers/plugins current and future. Doesn't sound like
this would result from what is proposed, and I'm not ready to accept
that as impossible. The notion that one could close this gap with
per-SBI translators appears to miss the point of the exercise. Can
someone point out what I've missed? If I understood correctly, I would
expect many of you to push back and seek something that better meets the
stated arch principal. Do we have the wrong goal or the wrong solution?
--
Cheers,
-drl
----------------------
*Dave Lenrow*
*Director, Partner Ecosystem*
*Plexxi*
*617 329 1861 <tel:617%20329%201861> *
_______________________________________________
controller-dev mailing list
controller-dev@...
<mailto:controller-dev@...>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
__
--
Cheers,
-drl
----------------------
*Dave Lenrow*
*Director, Partner Ecosystem*
*Plexxi*
*617 329 1861 *
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
-- Giovanni Meo Via del Serafico, 200 Telephone: +390651644000 00142, Roma Mobile: +393480700958 Italia Fax: +390651645917 VOIP: 8-3964000 “The pessimist complains about the wind; the optimist expects it to change; the realist adjusts the sails.” -- Wm. Arthur Ward IETF credo: "Rough consensus and running code"
|
|
|
Hi,
I will try to more clarify my view on model-driven SAL and abstractions.
In short:
Model driven SAL – we can define baseline models – catalog of functionality, SB plugins can define their
own models, which could also extends existing baseline models – applications which does not
care will use baseline models (and APIs), applications which cares will use extended models (and APIs).
For more information see bellow:
My comments & views inlined bellow:
> I interpret this as a goal to, where possible, enable one to write a service/application once and expect to get
> interoperability with all of the southbound drivers/plugins current and future.
> Doesn't sound like this would
> result from what is proposed, and I'm not ready to accept that as impossible.
With right abstractions it is not impossible.
The idea - and that one was not stressed enough is to have a set of baseline models (abstractions)
which could be used by most of the southbound plugins.
But there was also concern that we will loose powerful features of knowing the specifics of southbound plugin and
develop very specific applications.
The YANG and model-driven approach allows to define new modules by southbound plugins - they can extend
Baseline models - so applications could use baseline models if it is sufficient for them. If not, application could
use plugin specific extensions to model.
Basicly this will create several set of APIs - common APIs and specific APIs.
For example we will have baseline model for the support of multiple topologies and their layering (L2,L3, etc).
This model will define terms: topology, network node (vertex) and network link (edge).
Any application which needs to work with topology could use this baseline.
And we could have multiple southbound protocols which will extend the baseline topology model:
Openflow Plugin - defines Openflow topology (which is extension of baseline topology) and openflow specific information
OFConfig Plugin - defines Openflow topology and openflow specific information
"foo" Plugin - defines L7 topology, exports L7 topology.
And now when we have this specific plugins, but also abstraction (baseline topology) we can build application which
will analyze graph or visualize it, without knowing protocol specifics only using baseline model and we can also have
other applications which will use plugin specific functionality.
So far I mentioned topology example, but similar models with baseline models and extensions could be applied also
to other concepts e.g.:
- Path Provisioning (set up and tear down of paths - e.g. end-to-end Openflow, Openflow + tunnels, etc...)
- Tunnel Provisioning (setting up tunnels via OVSDB, via OFConfig + Netconf, via other protocols...)
- Statistics
- Policies (setting up policies via Netconf, Openflow etc.)
> The notion that one could close
> this gap with per-SBI translators appears to miss the point of the exercise. Can someone point out what
> I've missed?
Per-SBI translators are not allways the case - they are required if the wire protocol between southbound plugins
and network elements could not be directly expresed in model, has a different semantics or data needs some
preprocessing.
> If I understood correctly, I would expect many of you to push back and seek something that
> better meets the stated arch principal. Do we have the wrong goal or the wrong solution?
Goal is right.
Personally I think the solution with model-driven approach, base modules defining abstractions, is also right one.
From: David Lenrow [mailto:david.lenrow@...]
Sent: Wednesday, May 01, 2013 6:47 PM
To: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)
Subject: Fwd: [OpenDaylight Discuss] [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi Tony,
I was impressed by what was presented on the model driven SBI stuff. Hope you can help clear up my confusion as expressed in enclosed email thread (not assuming you always read the ODP email).
---------- Forwarded message ----------
From: David Lenrow <david.lenrow@...>
Date: Wed, May 1, 2013 at 12:45 PM
Subject: Re: [OpenDaylight Discuss] [controller-dev] Does SAL proposal satisfy arch principal #3?
To: Thomas Nadeau <tnadeau@...>
Cc: Colin Dixon <ckd@...>, "discuss@..." <discuss@...>, "controller-dev@..."
<controller-dev@...>
Hi Tom,
The discussion on the call related to the proposed model based system caused me this confusion. I really like the approach to defining and generating code that was presented. After hearing a description of a capability to allow new per-module
API extensions to be installed when a module loads, Rob asked (paraphrasing) doesn't this result in problems because the resulting APIs toward the upper layers would not be consistent/unified across plugin implementations (Principal #3)? The answer was that
translators could be developed from the just-loaded non-standard API to something common that would be presented upward. I would have asked for clarification on the call, but was in a bad spot on a mobile phone at the time.
Are folks suggesting that there will be two co-resident interfaces (both being called the SAL at present) with a model based, run-time extensible lower layer and a uniform/unified upper layer? How would features never anticipated in the
upper layer, yet exposed by the lower, be accessed? Have we gone in a circle?
Is the goal to allow both generic and custom APIs to be accessible from the service/app layer? This would allow a service/app to utilize any/all plugins using the set of common abstractions. It would also allow coordinated loading of both
a plugin with unique API features and a tightly coupled service/app that would do "special stuff" with unique awareness of features and API client code aligned with the custom APIs exposed.
The buffet of SDN technology provided by the two controller/platform submissions has exciting possibilities and I'm trying to understand the many choices. If this is all explained somewhere please send links to docs. I just saw links to
some tools/code from tony (CC'ed) and I'll go look. Maybe tony could help clarify subjects above by commenting on this thread?
Creating a unified plugin API that abstracts SBI so one can develop services that don't care which device interface loads is a problem I have not yet seen solved well. I'm hoping we can collectively make ODP the place where we nail it so
innovation can proliferate in the upper layers of the SDN stack.
toggle quoted messageShow quoted text
On Wed, May 1, 2013 at 7:37 AM, Thomas Nadeau < tnadeau@...> wrote:
I think that there's been some confusion because there are two different things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in the org.opendaylight.controller.sal.implementation.internal package/bundle. The idea is for it to provide the
key services which all other applications are based on. I think that it is exactly supposed to do what principle #3 says and provide a single northbound interface to multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday. The model-driven SAL is about having a single, declarative specification for a set of APIs and then
generating the bindings to access those APIs in a variety of different languages and environments. One obviously candidate set of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven approach IMHO, but we need to see some code in action to verify this works. I missed the presentation,
but as I understand it, the tools necessary to achieve the code-generation from the model will be made available soon. Is that correct?
Hopefully this clarifies some things and others can jump in to add more information.
--Colin
-----controller-dev-bounces@... wrote: -----
To:
discuss@...,
controller-dev@...
From: David Lenrow
Sent by:
controller-dev-bounces@...
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on yesterdays call, it seems like the SAL proposed does not satisfy architectural
principal #3: "Service Abstraction Layer (SAL): Where possible, allow for multiple southbound protocols to
present the same northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a service/application once and expect to get interoperability with all of the southbound drivers/plugins
current and future. Doesn't sound like this would result from what is proposed, and I'm not ready to accept that as impossible. The notion that one could close this gap with per-SBI translators appears to miss the point of the exercise. Can someone point
out what I've missed? If I understood correctly, I would expect many of you to push back and seek something that better meets the stated arch principal. Do we have the wrong goal or the wrong solution?
--
Cheers,
Director, Partner Ecosystem
--
Cheers,
Director, Partner Ecosystem
--
Cheers,
Director, Partner Ecosystem
|
|
|
David Lenrow <david.lenrow@...>
Thank you Giovanni and Tony. Your explanations are very helpful. The intention to support both standard and extended plugins and services was not at all clear from the discussion on the call Monday. I agree we can abstract and generalize a great deal of the common stuff, but will still need extensions for differentiated stuff. What you have described sounds like a great solution to allow both, with clever use of the features of the java platform. There can be well defined, shared objects in the model that would allow some functionality from a constrained-by-design "plugin" schema, and there can be new, run-time definable objects that benefit from the infrastructure you describe for connecting API aligned service and SB module instances. This infrastructure is brilliant. Now the challenge for folks who want to build works-with-any-plugin solutions is to define the right common SBI abstractions to maximize their utility for the use cases as you've suggested.
On Wed, May 1, 2013 at 5:18 PM, Giovanni Meo <gmeo@...> wrote:
Hi David,
let me try to address some of your doubts:
On 01-May-13 18:45, David Lenrow wrote:
Hi Tom,
The discussion on the call related to the proposed model based system caused me
this confusion. I really like the approach to defining and generating code that
was presented. After hearing a description of a capability to allow new
per-module API extensions to be installed when a module loads, Rob asked
(paraphrasing) doesn't this result in problems because the resulting APIs toward
the upper layers would not be consistent/unified across plugin implementations
(Principal #3)? The answer was that translators could be developed from the
just-loaded non-standard API to something common that would be presented upward.
I would have asked for clarification on the call, but was in a bad spot on a
mobile phone at the time.
Are folks suggesting that there will be two co-resident interfaces (both being
called the SAL at present) with a model based, run-time extensible lower layer
and a uniform/unified upper layer? How would features never anticipated in the
upper layer, yet exposed by the lower, be accessed? Have we gone in a circle?
As Colin pointed out there are two things that are called SAL, and apologize for that confusion in effect we have the:
- SAL: Service Abstraction Layer
- Model Driven SAL
The first one is the one existing infrastructure defined as a contract under directory opendaylight/sal/api. This defines a set of Java interfaces with supporting objects which are supposed to be the services that an application sitting on top of SAL expect from a protocol plugin and a protocol plugin would invoke toward the application. The interfaces are registered in the OSGi service registry and so the services can be injected in the system when a new plugin appear and can disappear when the plugin is removed.
The second one is the abstraction layer defined by mean of YANG, this is work in progress.
The first one will gradually move to the second one, by mean of replacing the current SAL service definition from Java to a Yang quasi-equivalent model and then let the Yang tool to generate the necessary Java code. Once the result is satisfactory the modeling of the contract will be only done in Yang. The side effect is that Yang model instead to be only written in the bundles part of the distribution can be loaded at runtime from protocols plugins for example implementing netconf or i2rs or any protocol that may be able to supplement yang augmentation to the base model written in the controller.
Now let me speak about the case of what we have now in the system and lets park for a moment the model driven approach, so to have a sense of what you can do today and you can try at home. Lets say you are creating a protocol plugin Foo which is exposing a new service that is not yet defined by SAL and is not yet considered by any upper layer application, which i think is your concern. So the story would go like this:
1) The protocol plugin developer looked at the catalog of the existing functionality (right now we have topology, data packets, inventory, flow programmer, HW read services) and figure out that there is not a way for her/him to get information on what node to connect. The protocol plugin developer than can define a new service let say called "Resource" and define the interface by which the protocol plugin should get notified of the IP to which to connect in order to start talking the protocol implemented. This interface could be either implemented directly into SAL.API bundle or let say someone wants to keep the interface for it's use so it can decide to create a bundle with the API definition called "sal.resource.api" where it just define the contract to which the protocol plugin should adhere as well the app. Now lets say this interface even if not contributed can satisfy multiple node type so a "sal.resource.impl" bundle need to be implemented to route the messages toward the correct Node.
2) The protocol plugin developer now it has a service it can implement because there is the contract defined in "sal.resource.api", it implements the interface and then export the service in the OSGi service registry. Well everyone is happy, but of course the protocol plugin never get invoked because there is no one calling the Resource service.
3.1) Someone integrating the controller for a customer realize ehi i have the implementation of the protocol plugin Foo but it's useless without the Resource service being called. It them implement an application which expose some REST api or a gui element that can read the IP of the nodes to connect too, so to start the protocol and then call the Resource service if present in the OSGi service registry. Now the protocol plugin Foo can get to work.
3.2) A variation on 3.1 someone integrating the controller realize that the application calling the Resource service is really lame, it just provide a new version and forget about the bundle with the lame implementation.
With this workflow i just wanted to show that there is no circle to break because if there is a never anticipated feature, first of all need to be defined someway, today by defining a java contract, then someone will implemented the provider and someone else can implement the consumer. Those entities don't need to be the same and there is no need to do at the same time. This is achieved thanks to the OSGi framework and the service dependency management, in fact it's very simple in OSGi to install consumer bundles without a provider in fact each bundle carries the dependency information in it and if those are not satisfied then simply the framework doesn't start the bundles that have unresolved dependency. The advantage of this modular approach is that encourage contract definition and then decouple producer consumer implementation. This is very popular in Java.
Is the goal to allow both generic and custom APIs to be accessible from the
service/app layer? This would allow a service/app to utilize any/all plugins
using the set of common abstractions. It would also allow coordinated loading of
both a plugin with unique API features and a tightly coupled service/app that
would do "special stuff" with unique awareness of features and API client code
aligned with the custom APIs exposed.
Yes, the reality is that we cannot uniform all the southbound to look the same else why some many variations, yet instead of having the applications to think in terms of specific southbound let say OF we want the applications on top of SAL to think in terms of services that can be provided by multiple southbound. Let pick for example data packet service, there are southbound protocol like openflow that provide it, but a BGP-LS/PCEP node won't be. Yet instead to create an application that process a certain kind of data packet assuming to work only on nodes that are OpenFlow, you can create that to say i depend on datapacket service and i expect the datapacket coming from network element to be DHCP packet. Such application will be able to work on any southbound protocol plugin that export data packet service.
Hope this make more clear and not more confusing :)
The buffet of SDN technology provided by the two controller/platform submissions
has exciting possibilities and I'm trying to understand the many choices. If
this is all explained somewhere please send links to docs. I just saw links to
some tools/code from tony (CC'ed) and I'll go look. Maybe tony could help
clarify subjects above by commenting on this thread?
Creating a unified plugin API that abstracts SBI so one can develop services
that don't care which device interface loads is a problem I have not yet seen
solved well. I'm hoping we can collectively make ODP the place where we nail it
so innovation can proliferate in the upper layers of the SDN stack.
In fact, we are not trying to find the holy grail, but are trying to abstract commonalities from concrete example and try to use them in network that have heterogeneous nodes, which is usually the case of a traditional network and will most likely be the case of an SDN network. Unfortunately one size fit all is not a reality in networking.
Thanks,
Giovanni
On Wed, May 1, 2013 at 7:37 AM, Thomas Nadeau < tnadeau@...
<mailto:tnadeau@...>> wrote:
From: Colin Dixon <ckd@... <mailto:ckd@...>>
Date: Wednesday, May 1, 2013 12:02 AM
<mailto:controller-dev@lists.opendaylight.org>>
Subject: Re: [OpenDaylight Discuss] [controller-dev] Does SAL proposal
satisfy arch principal #3?
I think that there's been some confusion because there are two different
things and we're calling both the SAL.
The first thing is the SAL that is currently in the code in
the org.opendaylight.controller. sal.implementation.internal
package/bundle. The idea is for it to provide the key services which all
other applications are based on. I think that it is exactly supposed to
do what principle #3 says and provide a single northbound interface to
multiple southbound protocols.
I agree, which is why I was totally confused by Dave's earlier message.
The second thing is the YANG-based model-driven SAL presented yesterday.
The model-driven SAL is about having a single, declarative specification
for a set of APIs and then generating the bindings to access those APIs
in a variety of different languages and environments. One obviously
candidate set of APIs would be the actual SAL in the code today.
Yes, this is my understanding as well. This is a very good data-driven
approach IMHO, but we need to see some code in action to verify this works.
I missed the presentation, but as I understand it, the tools necessary to
achieve the code-generation from the model will be made available soon. Is
that correct?
--Tom
Hopefully this clarifies some things and others can jump in to add more
information.
--Colin
----- controller-dev-bounces@lists.opendaylight.org
Sent by: controller-dev-bounces@lists.opendaylight.org
<mailto:controller-dev-bounces@...>
Date: 04/30/2013 04:20PM
Subject: [controller-dev] Does SAL proposal satisfy arch principal #3?
Hi folks. Maybe I'm missing something but based on the discussion on
yesterdays call, it seems like the SAL proposed does not satisfy
architectural principal #3: "*Service Abstraction Layer (SAL)*: Where
possible, allow for multiple southbound protocols to present the same
northbound service interfaces."
I interpret this as a goal to, where possible, enable one to write a
service/application once and expect to get interoperability with all of
the southbound drivers/plugins current and future. Doesn't sound like
this would result from what is proposed, and I'm not ready to accept
that as impossible. The notion that one could close this gap with
per-SBI translators appears to miss the point of the exercise. Can
someone point out what I've missed? If I understood correctly, I would
expect many of you to push back and seek something that better meets the
stated arch principal. Do we have the wrong goal or the wrong solution?
--
Cheers,
-drl
----------------------
*Dave Lenrow*
*Director, Partner Ecosystem*
*Plexxi*
*617 329 1861 <tel:617%20329%201861> *
<mailto:controller-dev@lists.opendaylight.org>
https://lists.opendaylight.org/mailman/listinfo/controller-dev
__
--
Cheers,
-drl
----------------------
*Dave Lenrow*
*Director, Partner Ecosystem*
*Plexxi*
* 617 329 1861 *
--
Giovanni Meo
Via del Serafico, 200 Telephone: +390651644000
00142, Roma Mobile: +393480700958
Italia Fax: +390651645917
VOIP: 8-3964000
“The pessimist complains about the wind;
the optimist expects it to change;
the realist adjusts the sails.” -- Wm. Arthur Ward
IETF credo: "Rough consensus and running code"
-- Cheers, -drl ---------------------- Dave Lenrow Director, Partner Ecosystem Plexxi
617 329 1861
|
|
|
