project-proposals@lists.opendaylight.org | [yangtools-dev] [controller-dev] Proposal to spin out MD-SAL

Home Messages Hashtags Subgroups

Date Date 1 - 4 of 4

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

Anil Vishnoi #278 I agree with Colin's comment. We face the similar issue with Openflowplugin project, where NSF/Models were living in controller and their implementation was in openflowplugin project. Everytime we pushed patch, we need to make sure that it get into controller first, it's artifact get published and then you push the openflowplugin project. Ed shared this pain with us :-), because we used to poke him a lot to merge patches to the controller, so that we can merge patch to openflowplugin. By sharing this experience i am not disagreeing to anything, just putting forward concerns that we should discuss before we go forward on this path. toggle quoted message Show quoted text On Thu, Feb 19, 2015 at 8:50 PM, Colin Dixon <colin@...> 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@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ yangtools-dev mailing list yangtools-dev@... https://lists.opendaylight.org/mailman/listinfo/yangtools-dev -- Thanks Anil
More All Messages By This Member
Anil Vishnoi #279 Robert, if my understanding of the proposal is correct, are we taking the API's out of controller and keeping the implementation in the controller? In general, what i have seen is that you keep the API's with the base platform, so that anybody who wants to write their own implementation can develop it and plug it to the base platform, but it seems like with the proposed approach it won't be possible? Sorry if i am totally off the track :). toggle quoted message Show quoted text On Thu, Feb 19, 2015 at 8:58 PM, Anil Vishnoi <vishnoianil@...> wrote: I agree with Colin's comment. We face the similar issue with Openflowplugin project, where NSF/Models were living in controller and their implementation was in openflowplugin project. Everytime we pushed patch, we need to make sure that it get into controller first, it's artifact get published and then you push the openflowplugin project. Ed shared this pain with us :-), because we used to poke him a lot to merge patches to the controller, so that we can merge patch to openflowplugin. By sharing this experience i am not disagreeing to anything, just putting forward concerns that we should discuss before we go forward on this path. On Thu, Feb 19, 2015 at 8:50 PM, Colin Dixon <colin@...> 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@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev _______________________________________________ yangtools-dev mailing list yangtools-dev@... https://lists.opendaylight.org/mailman/listinfo/yangtools-dev -- Thanks Anil -- Thanks Anil
More All Messages By This Member
Robert Varga #282 I completely agree about the pain. The difference now is that we are not talking about models, but rather Java APIs and for both YT and MD-SAL APIs we think the APIs are stable enough to be able to evolve compatibly. Bye, Robert On 02/19/2015 04:28 PM, Anil Vishnoi wrote: toggle quoted message Show quoted text I agree with Colin's comment. We face the similar issue with Openflowplugin project, where NSF/Models were living in controller and their implementation was in openflowplugin project. Everytime we pushed patch, we need to make sure that it get into controller first, it's artifact get published and then you push the openflowplugin project. Ed shared this pain with us :-), because we used to poke him a lot to merge patches to the controller, so that we can merge patch to openflowplugin. By sharing this experience i am not disagreeing to anything, just putting forward concerns that we should discuss before we go forward on this path. On Thu, Feb 19, 2015 at 8:50 PM, Colin Dixon <colin@...> 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 _______________________________________________ yangtools-dev mailing list yangtools-dev@... https://lists.opendaylight.org/mailman/listinfo/yangtools-dev -- Thanks Anil
More All Messages By This Member
Colin Dixon #304 So, I was thinking about this again recently and I realized the discussion largely petered out. I have to say, honestly, I don't really feel like we've gotten satisfactory answers to the key questions that people asked: * Will this cause issues with needed to merge pairs of patches that are inter-dependent? The claim is no, but frankly I don't believe it short of claiming we won't be changing the APIs. Actually, it might be better to let past code changes guide where project (or sub-project) boundaries should be. That is, produce a graph where each file is a node and there's add an edge between each pair of nodes when they're both affected by a commit. Then repeatedly find min-cuts in this graph until you get the number of sub-projects you think you want. * What impact will this have with making it possible for new developers to get involved? * Is there a compelling reason that this couldn't be done by simply using a bit of discipline and good directory structure? That is, do we really need the extra mechanism of new repositories or do we just need logical sub-projects? --Colin toggle quoted message Show quoted text On Thu, Feb 19, 2015 at 12:09 PM, Robert Varga <nite@...> wrote: I completely agree about the pain. The difference now is that we are not talking about models, but rather Java APIs and for both YT and MD-SAL APIs we think the APIs are stable enough to be able to evolve compatibly. Bye, Robert On 02/19/2015 04:28 PM, Anil Vishnoi wrote: I agree with Colin's comment. We face the similar issue with Openflowplugin project, where NSF/Models were living in controller and their implementation was in openflowplugin project. Everytime we pushed patch, we need to make sure that it get into controller first, it's artifact get published and then you push the openflowplugin project. Ed shared this pain with us :-), because we used to poke him a lot to merge patches to the controller, so that we can merge patch to openflowplugin. By sharing this experience i am not disagreeing to anything, just putting forward concerns that we should discuss before we go forward on this path. On Thu, Feb 19, 2015 at 8:50 PM, Colin Dixon <colin@...> 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 _______________________________________________ yangtools-dev mailing list yangtools-dev@... https://lists.opendaylight.org/mailman/listinfo/yangtools-dev -- Thanks Anil
More All Messages By This Member

1 - 4 of 4

1

Previous Topic Next Topic

Home Hashtags Subgroups Terms