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


Robert Varga
 

Can we continue the discussion, so we shake out any concerns before we get on that meeting?

Thanks,
Robert

On 02/19/2015 07:40 PM, Devin Avery wrote:

Sounds good then. We will hold the MD-SAL meeting next Tuesday the 24th and we can walk through the proposals and see if we can’t track some of the questions / responses etc.

Thank you!

Devin

Devin Avery



From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
Date: Thursday, February 19, 2015 at 12:56 PM
To: Colin Dixon <colin@...>, Devin Avery <davery@...>
Cc: "project-proposals@..." <project-proposals@...>, "tsc@..." <tsc@...>, "release@..." <release@...>, "controller-dev@..." <controller-dev@...>
Subject: RE: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

I agree,

This will be helpful to anyone to understand more clearly what we want to achieve with splitting

up.

 

Tony

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Colin Dixon
Sent: Thursday, February 19, 2015 6:50 PM
To: Devin Avery
Cc: project-proposals@...; tsc@...; release@...; controller-dev@...
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

 

I think that's a fantastic idea.

--Colin

 

On Thu, Feb 19, 2015 at 9:06 AM, Devin Avery <davery@...> wrote:

It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

 

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

 

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

 

Thank you!

 

Devin

 

Devin Avery

 

 

 

From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

 

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

 

/controller/opendaylight$ ls

adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

 

ad-sal is deprecated and it will be removed by next release

md-sal will be out of controller if new proposal goes through 

Existing md-sal nsf are already moved to openflowplugin project

netconf/restconf is also proposed as new project

networkconfiguration -- neutron is already on it's way out to the new project

 

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

 

Thanks

Anil

 

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:

Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert



On 02/19/2015 12:17 AM, Colin Dixon wrote:

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

 

 

 


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



 

--

Thanks

Anil


_______________________________________________
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


Devin Avery <davery@...>
 

Sounds good then. We will hold the MD-SAL meeting next Tuesday the 24th and we can walk through the proposals and see if we can’t track some of the questions / responses etc.

Thank you!

Devin

Devin Avery
Devin.Avery@...



From: "Tony Tkacik -X (ttkacik - Pantheon Technologies SRO at Cisco)" <ttkacik@...>
Date: Thursday, February 19, 2015 at 12:56 PM
To: Colin Dixon <colin@...>, Devin Avery <davery@...>
Cc: "project-proposals@..." <project-proposals@...>, "tsc@..." <tsc@...>, "release@..." <release@...>, "controller-dev@..." <controller-dev@...>
Subject: RE: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

I agree,

This will be helpful to anyone to understand more clearly what we want to achieve with splitting

up.

 

Tony

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Colin Dixon
Sent: Thursday, February 19, 2015 6:50 PM
To: Devin Avery
Cc: project-proposals@...; tsc@...; release@...; controller-dev@...
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

 

I think that's a fantastic idea.

--Colin

 

On Thu, Feb 19, 2015 at 9:06 AM, Devin Avery <davery@...> wrote:

It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

 

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

 

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

 

Thank you!

 

Devin

 

Devin Avery

 

 

 

From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

 

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

 

/controller/opendaylight$ ls

adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

 

ad-sal is deprecated and it will be removed by next release

md-sal will be out of controller if new proposal goes through 

Existing md-sal nsf are already moved to openflowplugin project

netconf/restconf is also proposed as new project

networkconfiguration -- neutron is already on it's way out to the new project

 

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

 

Thanks

Anil

 

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:

Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert



On 02/19/2015 12:17 AM, Colin Dixon wrote:

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

 

 

 


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



 

--

Thanks

Anil


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

 


Robert Varga
 

Agreed. Can we get some tech writers to attend, too? :)

Thanks,
Robert, who likes sensible wiki pages

On 02/19/2015 06:49 PM, Colin Dixon wrote:

I think that's a fantastic idea.

--Colin


On Thu, Feb 19, 2015 at 9:06 AM, Devin Avery <davery@...> wrote:
It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

Thank you!

Devin

Devin Avery



From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil

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




Robert Varga
 

My challenge is to define the current controller.git as a clear, sensible, defensible architectural piece :)

So the proposal is not actually moving the entire md-sal directory out, as there is a lot more than "the MD-SAL". If I were a developer coming in to the community from the outside, I would look at the overall architecture and pick the project based on that -- currently we simply do not have the project/architecture alignment to make that choice easy.

Bye,
Robert

On 02/19/2015 03:00 PM, Anil Vishnoi wrote:

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil


Tom Pantelis <tompantelis@...>
 

The proposal as I understand it is to move just the MD_SAL APIs along with the related yangtools pieces out of the controller. The MD_SAL impls (including clustering) would remain in the controller.

On Thu, Feb 19, 2015 at 12:55 PM, Colin Dixon <colin@...> wrote:
Both Anil and Devin have hit the nail on the head in terms of where I was going. My internal understanding from watching how the code was moving was that, over time, the controller was going to become just the MD-SAL with the other pieces deprecated, removed, or migrated into other projects.

It sounds like Robert's plan is the same, but to also move the MD-SAL out into it's own project at which point the controller would effectively cease to be an active project. There's nothing necessarily wrong with that as long as we understand and manage the implications including:

1.) Making sure we handle committer selection carefully.
2.) Making sure we keep the functionality at least as easy for others to consume as it is now and ideally improve it.
3.) Making sure that we don't end up with tightly coupled projects that will have interdependent patches that cause more intermittent build errors.

--Colin


On Thu, Feb 19, 2015 at 8:00 AM, Anil Vishnoi <vishnoianil@...> wrote:
Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil


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



Tony Tkacik
 

I agree,

This will be helpful to anyone to understand more clearly what we want to achieve with splitting

up.

 

Tony

 

From: controller-dev-bounces@... [mailto:controller-dev-bounces@...] On Behalf Of Colin Dixon
Sent: Thursday, February 19, 2015 6:50 PM
To: Devin Avery
Cc: project-proposals@...; tsc@...; release@...; controller-dev@...
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

 

I think that's a fantastic idea.

--Colin

 

On Thu, Feb 19, 2015 at 9:06 AM, Devin Avery <davery@...> wrote:

It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

 

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

 

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

 

Thank you!

 

Devin

 

Devin Avery

 

 

 

From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

 

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

 

/controller/opendaylight$ ls

adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

 

ad-sal is deprecated and it will be removed by next release

md-sal will be out of controller if new proposal goes through 

Existing md-sal nsf are already moved to openflowplugin project

netconf/restconf is also proposed as new project

networkconfiguration -- neutron is already on it's way out to the new project

 

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

 

Thanks

Anil

 

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:

Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert



On 02/19/2015 12:17 AM, Colin Dixon wrote:

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

 

 

 


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



 

--

Thanks

Anil


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

 


Colin Dixon
 

Both Anil and Devin have hit the nail on the head in terms of where I was going. My internal understanding from watching how the code was moving was that, over time, the controller was going to become just the MD-SAL with the other pieces deprecated, removed, or migrated into other projects.

It sounds like Robert's plan is the same, but to also move the MD-SAL out into it's own project at which point the controller would effectively cease to be an active project. There's nothing necessarily wrong with that as long as we understand and manage the implications including:

1.) Making sure we handle committer selection carefully.
2.) Making sure we keep the functionality at least as easy for others to consume as it is now and ideally improve it.
3.) Making sure that we don't end up with tightly coupled projects that will have interdependent patches that cause more intermittent build errors.

--Colin


On Thu, Feb 19, 2015 at 8:00 AM, Anil Vishnoi <vishnoianil@...> wrote:
Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil


Colin Dixon
 

I think that's a fantastic idea.

--Colin


On Thu, Feb 19, 2015 at 9:06 AM, Devin Avery <davery@...> wrote:
It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

Thank you!

Devin

Devin Avery
Devin.Avery@...



From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil

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



Colin Dixon
 

I had also already assumed that was obvious, but it's good to point it out.

--Colin


On Thu, Feb 19, 2015 at 10:07 AM, Robert Varga <nite@...> wrote:
Hello,

Argh, yes, I thought this bit was obvious.

What we want to have is this discussion finished and the projects are created by M5 (or by Lithium release the latest), so we can properly plan the transition and have it executed by the time Beryllium release opens.

Bye,
Robert


On 02/19/2015 04:15 PM, Edward Warnicke wrote:
Guys,

Quick point of order.  Today is M3 for offset 0, and thus it is to late for this split to happen for Lithium.

Is this just an ultra-early launch of the discussion for Beryllium?

Ed

On Thu, Feb 19, 2015 at 8:06 AM, Devin Avery <davery@...> wrote:
It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

Thank you!

Devin

Devin Avery



From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil

_______________________________________________
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



Robert Varga
 

Hello,

Argh, yes, I thought this bit was obvious.

What we want to have is this discussion finished and the projects are created by M5 (or by Lithium release the latest), so we can properly plan the transition and have it executed by the time Beryllium release opens.

Bye,
Robert

On 02/19/2015 04:15 PM, Edward Warnicke wrote:

Guys,

Quick point of order.  Today is M3 for offset 0, and thus it is to late for this split to happen for Lithium.

Is this just an ultra-early launch of the discussion for Beryllium?

Ed

On Thu, Feb 19, 2015 at 8:06 AM, Devin Avery <davery@...> wrote:
It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

Thank you!

Devin

Devin Avery



From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil

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




Edward Warnicke
 

Guys,

Quick point of order.  Today is M3 for offset 0, and thus it is to late for this split to happen for Lithium.

Is this just an ultra-early launch of the discussion for Beryllium?

Ed

On Thu, Feb 19, 2015 at 8:06 AM, Devin Avery <davery@...> wrote:
It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

Thank you!

Devin

Devin Avery
Devin.Avery@...



From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil

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



Devin Avery <davery@...>
 

It occurred to me that looking at the proposals in more detail on the weekly MD-SAL call would be a good way to get some of these general questions answered and help get the community informed.

Robert / Tony - would you guys mind walking us through the various MD-SAL proposals on next Tuesday’s MD-SAL call? We can record that and it will help use get a better understanding of the larger picture that you are envisioning etc.

Let me know if you are able to do that and I will be sure to do my best to draw a crowd! :)

Thank you!

Devin

Devin Avery
Devin.Avery@...



From: Anil Vishnoi <vishnoianil@...>
Date: Thursday, February 19, 2015 at 9:00 AM
To: Robert Varga <nite@...>
Cc: "project-proposals@..." <project-proposals@...>, "controller-dev@..." <controller-dev@...>, "release@..." <release@...>, "tsc@..." <tsc@...>
Subject: Re: [controller-dev] [Project-proposals] Splitting out Netconf / Restconf from Controller

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil


Anil Vishnoi
 

Well you can define something if that entity exist in some form :)..if i look at the controller code now following are the major pieces i see 

/controller/opendaylight$ ls
adsal  archetypes  commons  config  md-sal  netconf  networkconfiguration

ad-sal is deprecated and it will be removed by next release
md-sal will be out of controller if new proposal goes through 
Existing md-sal nsf are already moved to openflowplugin project
netconf/restconf is also proposed as new project
networkconfiguration -- neutron is already on it's way out to the new project

now few small pieces like config subsystem, archetypes will be there... i am not sure we want to call that a controller? Like colin, i am curious as well, if somebody ask me how is your  controller platform look like, as of now its hard for me to say anything concrete about it. I was under impression that we want to make controller a bit lightweight and just provide a very basic platform that user can start with to write their application, sorry to say but it seem like we are heading toward scrapping controller project itself :-) .Given that we will go on this path and split most of the core pieces in their own project, to me it looks like controller is going to be mere distribution file that picks up all the required pieces and build a controller for you. If the whole community agrees that this is best way to go forward, i am open to that as well, but i think we should think it through from end user (developer,users) perspective as well, because in my personal opinion end users feels that their is steep learning curve to write application on top of existing controller, and hopefully we are not making it worse.

Thanks
Anil

On Thu, Feb 19, 2015 at 4:32 PM, Robert Varga <nite@...> wrote:
Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert


On 02/19/2015 12:17 AM, Colin Dixon wrote:
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




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




--
Thanks
Anil


Robert Varga
 

Well... we have tried to scope the controller before and have gotten pretty much nowhere. It is very clear that the initial scope, as specified when the project was first conceived is quite overreaching.

In the past 18 months there was wide consensus is that the controller needs to be broken apart into manageable pieces. During the last design summit there was an attempt to frame what the controller is -- and failed to come up with a reasonable definition, as far as I know.

What are able to do, though, is to identify concrete, self-contained, functional blocks and their scope. If they end up being project-sized and can be staffed, they should be broken out as soon as it is feasible. The three proposals made so far (neutron, netconf/restconf, mdsal) are the result of the first iteration of this process.

I would like to continue the process until we arrive at a point when we can come up with a rock-solid definition of what the controller is and why. If we run out of code in the controller repository before that happens, well ... that's not something I would see as bad.

Bye,
Robert

On 02/19/2015 12:17 AM, Colin Dixon wrote:

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




Colin Dixon
 

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



Robert Varga
 

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


Colin Dixon
 

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