[release] [controller-dev] Splitting out Netconf / Restconf from Controller


Devin Avery <davery@...>
 

It basically seems like we are moving pieces out of the controller project until we get to the point that was is basically left will eventually be deprecated and will go away (i.e. become unsupported do to lack of people with knowledge on how it works). I remember this was proposed back at the design summit in September 14 and there was opposition to doing it this way (though I can’t remember the details of what the opposition was right now).

Generally speaking I am in support of creating concrete, specific projects with clear focus and resources but it would help if there was a “bigger picture” that someone could share (to Colin’s point about what is left in). I am sure folks have thought about this so if someone wouldn’t mind sharing their thoughts on the larger picture that would be great.

Could we possibly update this view (or create a new one) with what we are thinking is the end-game? https://wiki.opendaylight.org/view/Simultaneous_Release:Lithium_Release_Plan#Project_Dependency_Diagram

It would also help to list out what is left in the controller after we have split everything out (again to Colin’s point).

Thank you,

Devin

Devin Avery
Devin.Avery@...



From: Colin Dixon <colin@...>
Date: Wednesday, February 18, 2015 at 6:17 PM
To: Robert Varga <nite@...>
Cc: "tsc@..." <tsc@...>, "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>
Subject: Re: [release] [Project-proposals] [controller-dev] Splitting out Netconf / Restconf from Controller

I understand, but I'm not sure what you said doesn't equally apply to the AsyncDataBroker. Do we intend to also factor that out of the controller? What's left after you do that? I'm honestly curious.

I think it would help us draw some concrete lines around what is and is not "in scope" for the controller.

--Colin


On Wed, Feb 18, 2015 at 3:34 PM, Robert Varga <nite@...> wrote:
While the data representation and interactions of both RESTCONF and NETCONF lend them selves for the 'automagically there' part of the features, at the end of the day they are just protocol plugins which use MD-SAL APIs just as any other user can.

I do not believe we can sanely separate NB and SB aspects of the plugins. We could make place the dividing line at the 'raw protocol' boundary, but that will lead to a potentially needless public API abstracting things out. I think separating them out at the MD-SAL API boundary makes more sense -- that way we get rather immediate feedback and more inter-project oversight over how the APIs are being evolved.

Bottom line: architecturally they are already separate, splitting them up makes for much cleaner governance all over.

Bye,
Robert


On 02/18/2015 06:59 PM, Colin Dixon wrote:
So, I think it makes a lot of sense to move the NETCONF SB plugin to it's own project, but moving RESTCONF out seems... odd to me. It's as critical to the use of the MD-SAL (if not more so) than the Data Broker. It would seem like a bad idea to move something that critical to the MD-SAL, which is as in scope as could possibly be for the controller to a different project. Similarly, the NB NETCONF interface should probably be there, but I admit it's less used.

That's just my thoughts though.

Do others feel differently?

--Colin


On Tue, Feb 17, 2015 at 11: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


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




_______________________________________________
release mailing list
release@...https://lists.opendaylight.org/mailman/listinfo/release