1. Topics
  2. [controller-dev] Proposal to spin out MD-SAL

[controller-dev] Proposal to spin out MD-SAL

Colin Dixon
 

I'm curious how much of this could be done by having logical sub-projects that are well-organized and well-separated within the YANG tools repository. I understand that we'd like to factor apart the various pieces of functionality, but it's unclear what the advantage of factoring them apart into different projects vs. merely logically separating them within a project is.

In particular, there are some clear disadvantages to breaking things up into multiple projects. The most obvious of them being that if the projects are somewhat tightly coupled (as I would imagine these are), it will require us to frequently push groups of patches to multiple projects when things change and cause (hopefully brief) periods of inconsistency as patches are applied in one project but not (yet) applied in the other projects.

--Colin


On Thu, Feb 19, 2015 at 3:23 AM, Robert Varga <nite@...> wrote:
Hello everyone,

The YANG tools project would like to spin out a project containing the Java bindings and the code generators related to them. After analyzing where they fit conceptually, we have found that the Java bindings at this stage are tightly bound to the Binding Aware MD-SAL and thus they should live together, so they can be co-evolved with more ease.

Since the overall tune of the controller is trimming down, rather than dropping a large chunk of code into it, we would like to create a project, which will combine:
- MD-SAL binding-independent APIs and SPIs
- MD-SAL binding-aware APIs and SPIs
- MD-SAL binding-aware-to-binding-indepent connector
- YANG tools' Java code generators and support classes
to create a well-defined abstraction layer, without tying it to any particular implementation.

The details of the proposal are captured here: https://wiki.opendaylight.org/view/Project_Proposals:MD-SAL, comments and contributions are more than welcome.

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

The immediate advantages are:
- looser coupling between APIs and users
- stricter API governance, as the APIs will need to be evolved compatibly

In this concrete proposal we feel that:
- the set of APIs which will remain in the YANG Tools project are sufficiently stable to not cause inconsistency issues
- the Java bindings need further evolution, which needs to be coordinated with MD-SAL, so we want to preclude the inconsistencies mentioned below
- the split will increase clarity in how the code maps to the architecture

Thanks,
Robert

On 02/19/2015 04:20 PM, Colin Dixon wrote:

I'm curious how much of this could be done by having logical sub-projects that are well-organized and well-separated within the YANG tools repository. I understand that we'd like to factor apart the various pieces of functionality, but it's unclear what the advantage of factoring them apart into different projects vs. merely logically separating them within a project is.

In particular, there are some clear disadvantages to breaking things up into multiple projects. The most obvious of them being that if the projects are somewhat tightly coupled (as I would imagine these are), it will require us to frequently push groups of patches to multiple projects when things change and cause (hopefully brief) periods of inconsistency as patches are applied in one project but not (yet) applied in the other projects.

--Colin


On Thu, Feb 19, 2015 at 3:23 AM, Robert Varga <nite@...> wrote:
Hello everyone,

The YANG tools project would like to spin out a project containing the Java bindings and the code generators related to them. After analyzing where they fit conceptually, we have found that the Java bindings at this stage are tightly bound to the Binding Aware MD-SAL and thus they should live together, so they can be co-evolved with more ease.

Since the overall tune of the controller is trimming down, rather than dropping a large chunk of code into it, we would like to create a project, which will combine:
- MD-SAL binding-independent APIs and SPIs
- MD-SAL binding-aware APIs and SPIs
- MD-SAL binding-aware-to-binding-indepent connector
- YANG tools' Java code generators and support classes
to create a well-defined abstraction layer, without tying it to any particular implementation.

The details of the proposal are captured here: https://wiki.opendaylight.org/view/Project_Proposals:MD-SAL, comments and contributions are more than welcome.

Thanks,
Robert
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
Thomas D. Nadeau <tnadeau@...>
 


One question I have is: is this going to be easier, harder or the same for devs (esp new ones).  I think Anil raised this point earlier too. I am concerned with making things any more complex to code than they are today.  We’ve made a lot of progress in actually simplifying things over the past year, so I don’t want to go backwards.

—Tom

On Feb 19, 2015:12:06 PM, at 12:06 PM, Robert Varga <nite@...> wrote:

The immediate advantages are:
- looser coupling between APIs and users
- stricter API governance, as the APIs will need to be evolved compatibly

In this concrete proposal we feel that:
- the set of APIs which will remain in the YANG Tools project are sufficiently stable to not cause inconsistency issues
- the Java bindings need further evolution, which needs to be coordinated with MD-SAL, so we want to preclude the inconsistencies mentioned below
- the split will increase clarity in how the code maps to the architecture

Thanks,
Robert

On 02/19/2015 04:20 PM, Colin Dixon wrote:
I'm curious how much of this could be done by having logical sub-projects that are well-organized and well-separated within the YANG tools repository. I understand that we'd like to factor apart the various pieces of functionality, but it's unclear what the advantage of factoring them apart into different projects vs. merely logically separating them within a project is.

In particular, there are some clear disadvantages to breaking things up into multiple projects. The most obvious of them being that if the projects are somewhat tightly coupled (as I would imagine these are), it will require us to frequently push groups of patches to multiple projects when things change and cause (hopefully brief) periods of inconsistency as patches are applied in one project but not (yet) applied in the other projects.

--Colin


On Thu, Feb 19, 2015 at 3:23 AM, Robert Varga <nite@...> wrote:
Hello everyone,

The YANG tools project would like to spin out a project containing the Java bindings and the code generators related to them. After analyzing where they fit conceptually, we have found that the Java bindings at this stage are tightly bound to the Binding Aware MD-SAL and thus they should live together, so they can be co-evolved with more ease.

Since the overall tune of the controller is trimming down, rather than dropping a large chunk of code into it, we would like to create a project, which will combine:
- MD-SAL binding-independent APIs and SPIs
- MD-SAL binding-aware APIs and SPIs
- MD-SAL binding-aware-to-binding-indepent connector
- YANG tools' Java code generators and support classes
to create a well-defined abstraction layer, without tying it to any particular implementation.

The details of the proposal are captured here: https://wiki.opendaylight.org/view/Project_Proposals:MD-SAL, comments and contributions are more than welcome.

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


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