[controller-dev] Splitting out Netconf / Restconf from Controller
Tom Pantelis <tompantelis@...>
+1 On Tue, Feb 17, 2015 at 12:34 PM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:
|
|
Moiz Raja <moraja@...>
+1
toggle quoted message
Show quoted text
On Feb 17, 2015, at 9:39 AM, Tom Pantelis <tompantelis@...> wrote:
|
|
Tony Tkacik
Sorry, that section got lost when adding Wiki. – I already had it prepared, but somehow forgot to put on the wiki:
https://wiki.opendaylight.org/view/Project_Proposals:Netconf#Initial_Code
Tony
From: Edward Warnicke [mailto:hagbard@...]
Sent: Tuesday, February 17, 2015 11:03 PM To: Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) Cc: release@...; controller-dev@...; tsc@...; project-proposals@... Subject: Re: [controller-dev] Splitting out Netconf / Restconf from Controller
Could you be specific about which bundles/directories would be split out?
Wants to be clear on what's being proposed :)
Ed
On Tue, Feb 17, 2015 at 10:34 AM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote: Hi,
I want to propose splitting out last protocol-specific components from Controller project into separate Netconf project – which will contains implementation of Netconf and Restconf.
The proposal is available at: https://wiki.opendaylight.org/view/Project_Proposals:Netconf also as per Simultaneous Release plan since this project is spin-off from controller mostly, it should participate in Lithium Simultaneous Release.
@controller-commiters: Could you please chirp-in your view on split and if you are in favour of it?
Tony
|
|
Tom Pantelis <tompantelis@...>
Tony, I see you listed config-persister bundles. I thought they are part of the config system or am I wrong? Tom On Wed, Feb 18, 2015 at 3:12 AM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:
|
|
Devin Avery <davery@...>
If I am correct I believe the config-persister is the logic which copies the config files from a bundle and out under the /etc/opendaylight/karaf directory. Also, while I am not opposed to having restconf/netconf in the same project I am just curious what the logical tie together is (might be something I am missing)? At a high level they seem like completely separate services which could benefit from each being in their own (small) unique project to avoid any possible contamination. Also, I know I have been a bit distant as of late but that should be turning around @ the end of Feb and I wouldn’t mind caring my committer status onto these projects. This is the code that I have the best understanding on from the core controller and where I likely could best contribute. Also I think Tom Pantelis made a number of enhancements on Restconf/Netconf as well and if he is willing should be carried over as well. In general are there other committers on the controller that are interested in continuing on these new projects? Thank you! Devin Devin Avery Devin.Avery@... From: Tom Pantelis <tompantelis@...> Date: Wednesday, February 18, 2015 at 7:29 AM To: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...> Cc: "tsc@..." <tsc@...>, "controller-dev@..." <controller-dev@...>, "project-proposals@..." <project-proposals@...>, "release@..." <release@...> Subject: Re: [controller-dev] Splitting out Netconf / Restconf from Controller Tony, I see you listed config-persister bundles. I thought they are part of the config system or am I wrong? Tom On Wed, Feb 18, 2015 at 3:12 AM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:
|
|
Robert Varga
Hello Devin,
For a spin-out project, I do not believe we want to 'carry over' committer status at all, but rather look at the folk who are currently active in the area. Quite honestly, I see you mentioned on 1 netconf and 3 restconf patches. Tom has not been active on restconf/netconf since August. There are around 5 patches you have reviewed in the area (I did not count too closely). So I would suggest seeding the project with people currently active and re-evaluate based on contributions. On the technical side, config-persister provides a NETCONF-inspired XML frontent to config-manager's JMX API. The API may be seen as semi-independent, but the implementation relies on NETCONF heavily. The interlock you are missing is that RESTCONF is NETCONF with HTTP as a transport protocol (as opposed to SSH). Thanks, Robert On 02/18/2015 02:33 PM, Devin Avery wrote:
|
|
Thomas D. Nadeau <tnadeau@...>
Robert, I am not sure I agree with your assessment algorithm. Looking at Vaclav he has 0 commits and a couple reviews over the past 4 months according to Spectrometer: That seems to be even less involvement than the guys below that were removed in place of “people currently active on restconf/netconf” who actually have committed patches to the project albeit not in the timeline you designated as important. That aside, I am not entirely convinced that breaking out the Yangtools project from the core is a good idea given that RestConf is pretty much how everyone interacts with the controller today. The MD-SAL is effectively THE controller so to me at least, it seems that it should stay together. —Tom
|
|
Tony Tkacik
Tom, I withdraw Vaclav for now (he has currently lot of restconf maintaince contributions on review).
But also note that spectomer is not showing correct information (somehow it is missing lot of info for Helium)
I am not entirely convinced that breaking out the Yangtools project from the core is a good idea given that RestConf is pretty much how everyone interacts with the controller today. The MD-SAL is effectively THE controller so to me at least, it seems that it should stay together.
That is probably miscommunication from our side: we are not removing things from „core“ – we are drawing more clearer lines between them - Eg. YANGTools should deal only with YANG and data – no Netconf / Restconf specific functionality should be present there (that is yangtools part which should be migrated out of yangtools). - Netconf / Restconf allows external access to system – currently they need AAA (and AAA needs MD-SAL – that is cycle until netconf / mdsal / restconf are in same repository).
This actually will allow for cleaner and better defined contracts between component.
Tony
From: Thomas D. Nadeau [mailto:tnadeau@...]
Sent: Wednesday, February 18, 2015 3:56 PM To: Robert Varga Cc: Devin Avery; Tom Pantelis; Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco); tsc@...; controller-dev@...; project-proposals@...; release@... Subject: Re: [controller-dev] Splitting out Netconf / Restconf from Controller
Robert,
I am not sure I agree with your assessment algorithm. Looking at Vaclav he has 0 commits and a couple reviews over the past 4 months according to Spectrometer:
That seems to be even less involvement than the guys below that were removed in place of “people currently active on restconf/netconf” who actually have committed patches to the project albeit not in the timeline you designated as important.
That aside, I am not entirely convinced that breaking out the Yangtools project from the core is a good idea given that RestConf is pretty much how everyone interacts with the controller today. The MD-SAL is effectively THE controller so to me at least, it seems that it should stay together.
—Tom
|
|
Colin Dixon
Without taking a stance on any particular committer, it seems to me like it makes sense to have guidelines for how decisions like this are made. There was a lot of discussion about this on the TSC call last week for the creation of the Neutron northbound project. Essentially, we now have two precedents: 1.) The OpenFlow Plugin project which did start with the original OpenFlow plugin code from the controller, but rapidly moved away from that code and (as I understand it) always intended to that. In that case the project behaved like any other new project and basically listed anyone who credibly wanted to be a committer as a committer. 2.) The Neutron Northbound project, which (I think) used the rule that anyone who had made non-trivial modifications/reviews was invited to be a committer if they wanted. Just my advice. On Wed, Feb 18, 2015 at 10:43 AM, Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco) <ttkacik@...> wrote:
|
|