|
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
|
|
|
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:
toggle quoted message
Show quoted text
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
_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release
|
|
|
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
_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release
|
|
|
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:
toggle quoted message
Show quoted text
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
|
|
|
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
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
|
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@...
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
_______________________________________________
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@...
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
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
|
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:
toggle quoted message
Show quoted text
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
|
|
|
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
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
|
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@...
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
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
|
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
|
|
|
I agree,
This will be helpful to anyone to understand more clearly what we want to achieve with splitting
up.
Tony
toggle quoted message
Show quoted text
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! :)
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.
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
--
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
|
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
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
|
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:
toggle quoted message
Show quoted text
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
|
|
|
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:
toggle quoted message
Show quoted text
I think that's a fantastic idea.
--Colin
|
|
|
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@...
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! :) 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. 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
--
_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev
|
|
|
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:
toggle quoted message
Show quoted text
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
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! :)
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.
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
--
_______________________________________________
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
|
|
|
