|
Ronald van der Pol <Ronald.vanderPol@...>
On Wed, Sep 11, 2013 at 13:32:42 -0700, Srini Seetharaman wrote: As far as I can tell, the most popular controller for R&D today is
POX. The migration of the user base from NOX to POX happened because
of POX being pure-Python, lightweight and portable. I'm not sure if
it's easy for ODP to appeal to this audience. A more tangible goal is
for ODP to take over the user base of FloodLight that is more
industry-centric. We moved from NOX to FloodLight early last year. NOX developement was uncertain at that time and FloodLight had some nice features (Java, REST interface, topology discovery, topology view, host tracking). I know of several other NREN/academic colleagues who are using FL too. I don't know what the POX vs FL ratio is. rvdp
|
|
|
Ronald van der Pol <Ronald.vanderPol@...>
On Wed, Sep 11, 2013 at 08:15:21 +1000, David Meyer wrote: One thing we might want to keep in mind is that we want the ODP
controller to also become the primary controller people use for R&D.
Much of the work going on int he R&D community (as well as the NRENs,
world wide) is about Openflow. So it would seem that a reasonable base
edition would have the controller + openflow plugins + some basic
applications and "how to write an application" code. Just a thought
but independent of packaging we definitely will want to target this
(large and diverse) user community. Yes, a light weight version focussed on OpenFlow would be interesting us (SURFnet). Although multi tenancy (virtualisation) is also something we are exploring so that we can support multiple simultaneous researchers, projects, community networks, etc. rvdp
|
|
|
Yes.
toggle quoted message
Show quoted text
On 9/11/13 9:30 AM, "Ken Gray" <kgray@...> wrote: I guess, given the discussion of MD-SAL yesterday, this would be an
"adaptation" plugin.
On 9/11/13 10:46 AM, "Ken Gray" <kgray@...> wrote:
+1
Would be nice to have a "NOX to ODP" migration plan/doc (API shim?)
On 9/10/13 6:15 PM, "David Meyer" <dmm@...> wrote:
On Fri, Sep 6, 2013 at 11:13 PM, Masashi Kudo <m-kudo@...>
wrote:
I also like the idea to keep "Base Edition" minimal. One thing we might want to keep in mind is that we want the ODP
controller to also become the primary controller people use for R&D.
Much of the work going on int he R&D community (as well as the NRENs,
world wide) is about Openflow. So it would seem that a reasonable base
edition would have the controller + openflow plugins + some basic
applications and "how to write an application" code. Just a thought
but independent of packaging we definitely will want to target this
(large and diverse) user community.
--dmm
One more thought on this.
We may add more packages, such as "Enterprise Edition" or "Campus
Edition"
as Madhu san suggested.
In such a case, some projects which provide some framework or common
functionality may show up in multiple packages.
In order to make it a bit simpler, I would like to suggest to have
"OpenDaylight Advanced Edition" which should contain common
functionality
other than the basic one.
Other packages should derive from the basic package and the advanced
package.
Best regards,
--
M. Kudo
-----Original Message-----
From: tsc-bounces@...
[mailto:tsc-bounces@...] On Behalf Of Christopher
Price
Sent: Friday, September 06, 2013 4:23 AM
To: Christopher Price; Ed Warnicke (eaw);
discuss@...;
tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight
Release
Vehicles
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct,
and manipulate this proposal in meaningful ways. I have tried to
simplify
the basic edition while making it useful, as Ken pointed out, to ODL
users
looking to get started. I have also tried to include projects in only
one
release vehicle, this may upset some projects as I may be completely
wrong
with my placement, so jump in and start correcting the list (or the
way
it
is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price"
<christopher.price@...>
wrote:
Hi All,
Please engage in further discussion on the structure proposed on the
TSC call, in essence to me at least the proposal makes a lot of sense.
We don't want too many options and a limited amount of configuration
parameters etc for the end user.
Some thoughts to add to the proposal:
The basic package should contain the smallest possible
collection of functionality.
(OF and NetConf as potential south bounds with no application functions)
Other packages should derive from the basic package.
(Simplification of I&T activity, consistency of
packaging)
The release vehicles should provide targeted deployment
solutions
encompassing each included project.
(We should not try to overload release vehicles)
Once the rabbit is out of the hat of course it will be used in many
ways we cannot yet fathom, but it is important that we are clear in
the
uses we have intended the release to fulfill and communicate that
well.
I do like the idea of specific downloads that can be run. Tar-balls
are easy to share and distribute, if they come with a simple/common
command to get them up and running according to their vehicle it will
make the use of them all the easier.
Regards,
Chris
On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
As noted on the TSC call, we would really like some input from the
projects and consumers on what Vehicles would be useful. Please
speak
up :)
Ed
On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
The TSC needs to figure out what the Simultaneous Release
Vehicles
look like.
I've been asked to kick off a conversation here, to garner input
from the community, particularly the various projects, as to what
those should look like.
I suspect we don't want to simply release a 'kitchen sink' with
everything rolled into it, but rather would like to release a
relatively small number (think 3-5) of 'flavors' containing things
that thematically go together.
Examples of how we might proceed (and I am not advocating for
anything here, just pointing out examples to get conversation
going)
might be things like:
OpenDaylight Base Edition
OpenDaylight Service Provider Edition OpenDaylight Cloud Edition
Thoughts?
Ed _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
|
|
|
Madhu Venugopal (vmadhu) <vmadhu@...>
Ed,
Good idea and I would like to volunteer for that :-)
-Madhu
toggle quoted message
Show quoted text
On 9/13/13 9:55 AM, "Ed Warnicke (eaw)" <eaw@...> wrote: I suspect we could produce an archetype for a Jython app bundleŠ that
would make it
quite easier to transition...
Ed
On Sep 11, 2013, at 3:32 PM, Srini Seetharaman
<srini.seetharaman@...> wrote:
And a "how to write an application" code is quite necessary.
It will be helpful for new users/developers if there includes a simple
template demonstrating the basic pkt process.
I guess the simple L2-forwarding would be fair enough. There are independent app-developer tutorials that use the basic
edition and show how to build the L2-learning-switch:
http://archive.openflow.org/wk/index.php?title=OpenDayLight_Tutorial
Would be nice to have a "NOX to ODP" migration plan/doc (API shim?) The above tutorial tries to approach ODP from the perspective of folks
used to programming in other controllers. I can help write a separate
migration plan if that will be useful.
One thing we might want to keep in mind is that we want the ODP
controller to also become the primary controller people use for R&D.
As far as I can tell, the most popular controller for R&D today is
POX. The migration of the user base from NOX to POX happened because
of POX being pure-Python, lightweight and portable. I'm not sure if
it's easy for ODP to appeal to this audience. A more tangible goal is
for ODP to take over the user base of FloodLight that is more
industry-centric.
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
|
|
|
Ed Warnicke (eaw) <eaw@...>
I suspect we could produce an archetype for a Jython app bundle… that would make it
quite easier to transition...
Ed
toggle quoted message
Show quoted text
On Sep 11, 2013, at 3:32 PM, Srini Seetharaman <srini.seetharaman@...> wrote: And a "how to write an application" code is quite necessary.
It will be helpful for new users/developers if there includes a simple template demonstrating the basic pkt process.
I guess the simple L2-forwarding would be fair enough. There are independent app-developer tutorials that use the basic
edition and show how to build the L2-learning-switch:
http://archive.openflow.org/wk/index.php?title=OpenDayLight_Tutorial
Would be nice to have a "NOX to ODP" migration plan/doc (API shim?) The above tutorial tries to approach ODP from the perspective of folks
used to programming in other controllers. I can help write a separate
migration plan if that will be useful.
One thing we might want to keep in mind is that we want the ODP
controller to also become the primary controller people use for R&D.
As far as I can tell, the most popular controller for R&D today is
POX. The migration of the user base from NOX to POX happened because
of POX being pure-Python, lightweight and portable. I'm not sure if
it's easy for ODP to appeal to this audience. A more tangible goal is
for ODP to take over the user base of FloodLight that is more
industry-centric.
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
|
|
|
And a "how to write an application" code is quite necessary.
It will be helpful for new users/developers if there includes a simple template demonstrating the basic pkt process.
I guess the simple L2-forwarding would be fair enough. There are independent app-developer tutorials that use the basic edition and show how to build the L2-learning-switch: http://archive.openflow.org/wk/index.php?title=OpenDayLight_TutorialWould be nice to have a "NOX to ODP" migration plan/doc (API shim?) The above tutorial tries to approach ODP from the perspective of folks used to programming in other controllers. I can help write a separate migration plan if that will be useful. One thing we might want to keep in mind is that we want the ODP
controller to also become the primary controller people use for R&D.
As far as I can tell, the most popular controller for R&D today is POX. The migration of the user base from NOX to POX happened because of POX being pure-Python, lightweight and portable. I'm not sure if it's easy for ODP to appeal to this audience. A more tangible goal is for ODP to take over the user base of FloodLight that is more industry-centric.
|
|
|
I guess, given the discussion of MD-SAL yesterday, this would be an
"adaptation" plugin.
toggle quoted message
Show quoted text
On 9/11/13 10:46 AM, "Ken Gray" <kgray@...> wrote: +1
Would be nice to have a "NOX to ODP" migration plan/doc (API shim?)
On 9/10/13 6:15 PM, "David Meyer" <dmm@...> wrote:
On Fri, Sep 6, 2013 at 11:13 PM, Masashi Kudo <m-kudo@...>
wrote:
I also like the idea to keep "Base Edition" minimal. One thing we might want to keep in mind is that we want the ODP
controller to also become the primary controller people use for R&D.
Much of the work going on int he R&D community (as well as the NRENs,
world wide) is about Openflow. So it would seem that a reasonable base
edition would have the controller + openflow plugins + some basic
applications and "how to write an application" code. Just a thought
but independent of packaging we definitely will want to target this
(large and diverse) user community.
--dmm
One more thought on this.
We may add more packages, such as "Enterprise Edition" or "Campus
Edition"
as Madhu san suggested.
In such a case, some projects which provide some framework or common
functionality may show up in multiple packages.
In order to make it a bit simpler, I would like to suggest to have
"OpenDaylight Advanced Edition" which should contain common
functionality
other than the basic one.
Other packages should derive from the basic package and the advanced
package.
Best regards,
--
M. Kudo
-----Original Message-----
From: tsc-bounces@...
[mailto:tsc-bounces@...] On Behalf Of Christopher
Price
Sent: Friday, September 06, 2013 4:23 AM
To: Christopher Price; Ed Warnicke (eaw);
discuss@...;
tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight
Release
Vehicles
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct,
and manipulate this proposal in meaningful ways. I have tried to
simplify
the basic edition while making it useful, as Ken pointed out, to ODL
users
looking to get started. I have also tried to include projects in only
one
release vehicle, this may upset some projects as I may be completely
wrong
with my placement, so jump in and start correcting the list (or the way
it
is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price"
<christopher.price@...>
wrote:
Hi All,
Please engage in further discussion on the structure proposed on the
TSC call, in essence to me at least the proposal makes a lot of sense.
We don't want too many options and a limited amount of configuration
parameters etc for the end user.
Some thoughts to add to the proposal:
The basic package should contain the smallest possible
collection of functionality.
(OF and NetConf as potential south bounds with no application functions)
Other packages should derive from the basic package.
(Simplification of I&T activity, consistency of
packaging)
The release vehicles should provide targeted deployment
solutions
encompassing each included project.
(We should not try to overload release vehicles)
Once the rabbit is out of the hat of course it will be used in many
ways we cannot yet fathom, but it is important that we are clear in the
uses we have intended the release to fulfill and communicate that well.
I do like the idea of specific downloads that can be run. Tar-balls
are easy to share and distribute, if they come with a simple/common
command to get them up and running according to their vehicle it will
make the use of them all the easier.
Regards,
Chris
On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
As noted on the TSC call, we would really like some input from the
projects and consumers on what Vehicles would be useful. Please speak
up :)
Ed
On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
The TSC needs to figure out what the Simultaneous Release
Vehicles
look like.
I've been asked to kick off a conversation here, to garner input
from the community, particularly the various projects, as to what
those should look like.
I suspect we don't want to simply release a 'kitchen sink' with
everything rolled into it, but rather would like to release a
relatively small number (think 3-5) of 'flavors' containing things
that thematically go together.
Examples of how we might proceed (and I am not advocating for
anything here, just pointing out examples to get conversation going)
might be things like:
OpenDaylight Base Edition
OpenDaylight Service Provider Edition OpenDaylight Cloud Edition
Thoughts?
Ed _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
+1
Would be nice to have a "NOX to ODP" migration plan/doc (API shim?)
toggle quoted message
Show quoted text
On 9/10/13 6:15 PM, "David Meyer" <dmm@...> wrote: On Fri, Sep 6, 2013 at 11:13 PM, Masashi Kudo <m-kudo@...>
wrote:
I also like the idea to keep "Base Edition" minimal. One thing we might want to keep in mind is that we want the ODP
controller to also become the primary controller people use for R&D.
Much of the work going on int he R&D community (as well as the NRENs,
world wide) is about Openflow. So it would seem that a reasonable base
edition would have the controller + openflow plugins + some basic
applications and "how to write an application" code. Just a thought
but independent of packaging we definitely will want to target this
(large and diverse) user community.
--dmm
One more thought on this.
We may add more packages, such as "Enterprise Edition" or "Campus
Edition"
as Madhu san suggested.
In such a case, some projects which provide some framework or common
functionality may show up in multiple packages.
In order to make it a bit simpler, I would like to suggest to have
"OpenDaylight Advanced Edition" which should contain common
functionality
other than the basic one.
Other packages should derive from the basic package and the advanced
package.
Best regards,
--
M. Kudo
-----Original Message-----
From: tsc-bounces@...
[mailto:tsc-bounces@...] On Behalf Of Christopher
Price
Sent: Friday, September 06, 2013 4:23 AM
To: Christopher Price; Ed Warnicke (eaw);
discuss@...;
tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight
Release
Vehicles
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct,
and manipulate this proposal in meaningful ways. I have tried to
simplify
the basic edition while making it useful, as Ken pointed out, to ODL
users
looking to get started. I have also tried to include projects in only
one
release vehicle, this may upset some projects as I may be completely
wrong
with my placement, so jump in and start correcting the list (or the way
it
is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
Hi All,
Please engage in further discussion on the structure proposed on the
TSC call, in essence to me at least the proposal makes a lot of sense.
We don't want too many options and a limited amount of configuration
parameters etc for the end user.
Some thoughts to add to the proposal:
The basic package should contain the smallest possible
collection of functionality.
(OF and NetConf as potential south bounds with no application functions)
Other packages should derive from the basic package.
(Simplification of I&T activity, consistency of
packaging)
The release vehicles should provide targeted deployment solutions
encompassing each included project.
(We should not try to overload release vehicles)
Once the rabbit is out of the hat of course it will be used in many
ways we cannot yet fathom, but it is important that we are clear in the
uses we have intended the release to fulfill and communicate that well.
I do like the idea of specific downloads that can be run. Tar-balls
are easy to share and distribute, if they come with a simple/common
command to get them up and running according to their vehicle it will
make the use of them all the easier.
Regards,
Chris
On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
As noted on the TSC call, we would really like some input from the
projects and consumers on what Vehicles would be useful. Please speak
up :)
Ed
On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
The TSC needs to figure out what the Simultaneous Release
Vehicles
look like.
I've been asked to kick off a conversation here, to garner input
from the community, particularly the various projects, as to what
those should look like.
I suspect we don't want to simply release a 'kitchen sink' with
everything rolled into it, but rather would like to release a
relatively small number (think 3-5) of 'flavors' containing things
that thematically go together.
Examples of how we might proceed (and I am not advocating for
anything here, just pointing out examples to get conversation going)
might be things like:
OpenDaylight Base Edition
OpenDaylight Service Provider Edition OpenDaylight Cloud Edition
Thoughts?
Ed _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
Baohua Yang
Yes. And a "how to write an application" code is quite necessary. It will be helpful for new users/developers if there includes a simple template demonstrating the basic pkt process.
I guess the simple L2-forwarding would be fair enough.
On Wed, Sep 11, 2013 at 6:15 AM, David Meyer <dmm@...> wrote:
On Fri, Sep 6, 2013 at 11:13 PM, Masashi Kudo < m-kudo@...> wrote:
> I also like the idea to keep "Base Edition" minimal.
controller to also become the primary controller people use for R&D.
Much of the work going on int he R&D community (as well as the NRENs,
world wide) is about Openflow. So it would seem that a reasonable base
edition would have the controller + openflow plugins + some basic
applications and "how to write an application" code. Just a thought
but independent of packaging we definitely will want to target this
(large and diverse) user community.
--dmm
>
> One more thought on this.
> We may add more packages, such as "Enterprise Edition" or "Campus Edition"
> as Madhu san suggested.
> In such a case, some projects which provide some framework or common
> functionality may show up in multiple packages.
>
> In order to make it a bit simpler, I would like to suggest to have
> "OpenDaylight Advanced Edition" which should contain common functionality
> other than the basic one.
> Other packages should derive from the basic package and the advanced
> package.
>
> Best regards,
> --
> M. Kudo
>
> -----Original Message-----
> From: tsc-bounces@...
> [mailto: tsc-bounces@...] On Behalf Of Christopher Price
> Sent: Friday, September 06, 2013 4:23 AM
> To: Christopher Price; Ed Warnicke (eaw); discuss@...;
> tsc@...; Luis Gomez
> Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release
> Vehicles
>
> So I'm going to throw out a discussion on proposed bundling of
> projects/release vehicles.
>
> Please don't beat me for the proposal, but do feel free to discuss, correct,
> and manipulate this proposal in meaningful ways. I have tried to simplify
> the basic edition while making it useful, as Ken pointed out, to ODL users
> looking to get started. I have also tried to include projects in only one
> release vehicle, this may upset some projects as I may be completely wrong
> with my placement, so jump in and start correcting the list (or the way it
> is proposed for that matter).
>
>
> * OpenDaylight Base Edition
> Controller
> OpenFlow(s)
> Netconf
> YangTools*
>
>
> * OpenDaylight Service Provider Edition
> ODL Basic Edition
> BGP-LS/PCEP
> Defence4All
> Lisp Flow Mapping
> SNMP4SDN
>
>
> * OpenDaylight Cloud Edition
> ODL Basic Edition
> OVSDB
> OpenDove
> VTN
> Affinity Metadata Service
>
> Regards,
>
> Chris
>
>
>
>
>
> On 9/5/13 12:10 PM, "Christopher Price" < christopher.price@...>
> wrote:
>
>>Hi All,
>>
>>Please engage in further discussion on the structure proposed on the
>>TSC call, in essence to me at least the proposal makes a lot of sense.
>>We don't want too many options and a limited amount of configuration
>>parameters etc for the end user.
>>
>>Some thoughts to add to the proposal:
>> The basic package should contain the smallest possible collection of
>
>>functionality.
>> (OF and NetConf as potential south bounds with no
> application functions)
>> Other packages should derive from the basic package.
>> (Simplification of I&T activity, consistency of packaging)
>> The release vehicles should provide targeted deployment solutions
>>encompassing each included project.
>> (We should not try to overload release vehicles)
>>
>>Once the rabbit is out of the hat of course it will be used in many
>>ways we cannot yet fathom, but it is important that we are clear in the
>>uses we have intended the release to fulfill and communicate that well.
>>
>>I do like the idea of specific downloads that can be run. Tar-balls
>>are easy to share and distribute, if they come with a simple/common
>>command to get them up and running according to their vehicle it will
>>make the use of them all the easier.
>>
>>Regards,
>> Chris
>>
>>
>>
>>
>>On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" < eaw@...> wrote:
>>
>>>As noted on the TSC call, we would really like some input from the
>>>projects and consumers on what Vehicles would be useful. Please speak
>>>up :)
>>>
>>>Ed
>>>On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) < eaw@...> wrote:
>>>
>>>> Guys,
>>>> The TSC needs to figure out what the Simultaneous Release Vehicles
>>>>look like.
>>>> I've been asked to kick off a conversation here, to garner input
>>>>from the community, particularly the various projects, as to what
>>>>those should look like.
>>>>
>>>> I suspect we don't want to simply release a 'kitchen sink' with
>>>>everything rolled into it, but rather would like to release a
>>>>relatively small number (think 3-5) of 'flavors' containing things
>>>>that thematically go together.
>>>>
>>>> Examples of how we might proceed (and I am not advocating for
>>>>anything here, just pointing out examples to get conversation going)
>>>>might be things like:
>>>>
>>>> OpenDaylight Base Edition
>>>> OpenDaylight Service Provider Edition OpenDaylight Cloud Edition
>>>>
>>>> Thoughts?
>>>>
>>>> Ed
>>>
>>>_______________________________________________
>>>Discuss mailing list
>>> Discuss@...
>>> https://lists.opendaylight.org/mailman/listinfo/discuss
>>
>>_______________________________________________
>>Discuss mailing list
>> Discuss@...
>> https://lists.opendaylight.org/mailman/listinfo/discuss
>
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>
> _______________________________________________
> Discuss mailing list
> Discuss@...
> https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
-- Best wishes!
Baohua
|
|
|
On Fri, Sep 6, 2013 at 11:13 PM, Masashi Kudo <m-kudo@...> wrote: I also like the idea to keep "Base Edition" minimal. One thing we might want to keep in mind is that we want the ODP controller to also become the primary controller people use for R&D. Much of the work going on int he R&D community (as well as the NRENs, world wide) is about Openflow. So it would seem that a reasonable base edition would have the controller + openflow plugins + some basic applications and "how to write an application" code. Just a thought but independent of packaging we definitely will want to target this (large and diverse) user community. --dmm
One more thought on this.
We may add more packages, such as "Enterprise Edition" or "Campus Edition"
as Madhu san suggested.
In such a case, some projects which provide some framework or common
functionality may show up in multiple packages.
In order to make it a bit simpler, I would like to suggest to have
"OpenDaylight Advanced Edition" which should contain common functionality
other than the basic one.
Other packages should derive from the basic package and the advanced
package.
Best regards,
--
M. Kudo
-----Original Message-----
From: tsc-bounces@...
[mailto:tsc-bounces@...] On Behalf Of Christopher Price
Sent: Friday, September 06, 2013 4:23 AM
To: Christopher Price; Ed Warnicke (eaw); discuss@...;
tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release
Vehicles
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss, correct,
and manipulate this proposal in meaningful ways. I have tried to simplify
the basic edition while making it useful, as Ken pointed out, to ODL users
looking to get started. I have also tried to include projects in only one
release vehicle, this may upset some projects as I may be completely wrong
with my placement, so jump in and start correcting the list (or the way it
is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
Hi All,
Please engage in further discussion on the structure proposed on the
TSC call, in essence to me at least the proposal makes a lot of sense.
We don't want too many options and a limited amount of configuration
parameters etc for the end user.
Some thoughts to add to the proposal:
The basic package should contain the smallest possible collection of functionality.
(OF and NetConf as potential south bounds with no application functions)
Other packages should derive from the basic package.
(Simplification of I&T activity, consistency of packaging)
The release vehicles should provide targeted deployment solutions
encompassing each included project.
(We should not try to overload release vehicles)
Once the rabbit is out of the hat of course it will be used in many
ways we cannot yet fathom, but it is important that we are clear in the
uses we have intended the release to fulfill and communicate that well.
I do like the idea of specific downloads that can be run. Tar-balls
are easy to share and distribute, if they come with a simple/common
command to get them up and running according to their vehicle it will
make the use of them all the easier.
Regards,
Chris
On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
As noted on the TSC call, we would really like some input from the
projects and consumers on what Vehicles would be useful. Please speak
up :)
Ed
On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
The TSC needs to figure out what the Simultaneous Release Vehicles
look like.
I've been asked to kick off a conversation here, to garner input
from the community, particularly the various projects, as to what
those should look like.
I suspect we don't want to simply release a 'kitchen sink' with
everything rolled into it, but rather would like to release a
relatively small number (think 3-5) of 'flavors' containing things
that thematically go together.
Examples of how we might proceed (and I am not advocating for
anything here, just pointing out examples to get conversation going)
might be things like:
OpenDaylight Base Edition
OpenDaylight Service Provider Edition OpenDaylight Cloud Edition
Thoughts?
Ed _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
|
|
|
Luis Gomez <luis.gomez@...>
Yes, I think this could be the right approach, people will be free to build whatever they want but we have to integrate and test a few (hopefully) release vehicles.
toggle quoted message
Show quoted text
From: Ed Warnicke (eaw) [mailto:eaw@...]
Sent: Friday, September 06, 2013 10:30 AM
To: Baohua Yang
Cc: Christopher Price; discuss@...; tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles
Baohua,
Folks can put the lego block together however they want (its one of the nice things about
OSGI) :) But we do want to put out a few carefully integrated flavors ourselves :)
Ed
Love the naming.
The three versions are good baseline.
Beside, is it possible to provide a "customizable" release?
Users can selectively build what their need easily, and download app bundles from an "ODL AppStore".
On Fri, Sep 6, 2013 at 3:22 AM, Christopher Price <christopher.price@...> wrote:
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct, and manipulate this proposal in meaningful ways. I have tried to
simplify the basic edition while making it useful, as Ken pointed out, to
ODL users looking to get started. I have also tried to include projects
in only one release vehicle, this may upset some projects as I may be
completely wrong with my placement, so jump in and start correcting the
list (or the way it is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
>Hi All,
>
>Please engage in further discussion on the structure proposed on the TSC
>call, in essence to me at least the proposal makes a lot of sense. We
>don't want too many options and a limited amount of configuration
>parameters etc for the end user.
>
>Some thoughts to add to the proposal:
> The basic package should contain the smallest possible collection of
>functionality.
> (OF and NetConf as potential south bounds with no application functions)
> Other packages should derive from the basic package.
> (Simplification of I&T activity, consistency of packaging)
> The release vehicles should provide targeted deployment solutions
>encompassing each included project.
> (We should not try to overload release vehicles)
>
>Once the rabbit is out of the hat of course it will be used in many ways
>we cannot yet fathom, but it is important that we are clear in the uses we
>have intended the release to fulfill and communicate that well.
>
>I do like the idea of specific downloads that can be run. Tar-balls are
>easy to share and distribute, if they come with a simple/common command to
>get them up and running according to their vehicle it will make the use of
>them all the easier.
>
>Regards,
> Chris
>
>
>
>
>On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
>
>>As noted on the TSC call, we would really like some input from the
>>projects and consumers on
>>what Vehicles would be useful. Please speak up :)
>>
>>Ed
>>On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
>>
>>> Guys,
>>> The TSC needs to figure out what the Simultaneous Release Vehicles
>>>look like.
>>> I've been asked to kick off a conversation here, to garner input from
>>>the community, particularly
>>> the various projects, as to what those should look like.
>>>
>>> I suspect we don't want to simply release a 'kitchen sink' with
>>>everything rolled into it, but
>>> rather would like to release a relatively small number (think 3-5) of
>>>'flavors' containing things
>>> that thematically go together.
>>>
>>> Examples of how we might proceed (and I am not advocating for anything
>>>here, just pointing
>>> out examples to get conversation going) might be things like:
>>>
>>> OpenDaylight Base Edition
>>> OpenDaylight Service Provider Edition
>>> OpenDaylight Cloud Edition
>>>
>>> Thoughts?
>>>
>>> Ed
>>
>>_______________________________________________
>>Discuss mailing list
>>Discuss@...
>>https://lists.opendaylight.org/mailman/listinfo/discuss
>
>_______________________________________________
>Discuss mailing list
>Discuss@...
>https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
--
Best wishes!
Baohua
|
|
|
Ed Warnicke (eaw) <eaw@...>
Baohua,
Folks can put the lego block together however they want (its one of the nice things about
OSGI) :) But we do want to put out a few carefully integrated flavors ourselves :)
Love the naming.
The three versions are good baseline.
Beside, is it possible to provide a "customizable" release?
Just like the linux os.
Users can selectively build what their need easily, and download app bundles from an "ODL AppStore".
|
|
|
Masashi Kudo <m-kudo@...>
I also like the idea to keep "Base Edition" minimal.
One more thought on this.
We may add more packages, such as "Enterprise Edition" or "Campus Edition"
as Madhu san suggested.
In such a case, some projects which provide some framework or common
functionality may show up in multiple packages.
In order to make it a bit simpler, I would like to suggest to have
"OpenDaylight Advanced Edition" which should contain common functionality
other than the basic one.
Other packages should derive from the basic package and the advanced
package.
Best regards,
--
M. Kudo
toggle quoted message
Show quoted text
-----Original Message----- From: tsc-bounces@... [mailto:tsc-bounces@...] On Behalf Of Christopher Price Sent: Friday, September 06, 2013 4:23 AM To: Christopher Price; Ed Warnicke (eaw); discuss@...; tsc@...; Luis Gomez Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles So I'm going to throw out a discussion on proposed bundling of projects/release vehicles. Please don't beat me for the proposal, but do feel free to discuss, correct, and manipulate this proposal in meaningful ways. I have tried to simplify the basic edition while making it useful, as Ken pointed out, to ODL users looking to get started. I have also tried to include projects in only one release vehicle, this may upset some projects as I may be completely wrong with my placement, so jump in and start correcting the list (or the way it is proposed for that matter). * OpenDaylight Base Edition Controller OpenFlow(s) Netconf YangTools* * OpenDaylight Service Provider Edition ODL Basic Edition BGP-LS/PCEP Defence4All Lisp Flow Mapping SNMP4SDN * OpenDaylight Cloud Edition ODL Basic Edition OVSDB OpenDove VTN Affinity Metadata Service Regards, Chris On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...> wrote: Hi All,
Please engage in further discussion on the structure proposed on the
TSC call, in essence to me at least the proposal makes a lot of sense.
We don't want too many options and a limited amount of configuration
parameters etc for the end user.
Some thoughts to add to the proposal:
The basic package should contain the smallest possible collection of functionality.
(OF and NetConf as potential south bounds with no application functions) Other packages should derive from the basic package.
(Simplification of I&T activity, consistency of packaging)
The release vehicles should provide targeted deployment solutions
encompassing each included project.
(We should not try to overload release vehicles)
Once the rabbit is out of the hat of course it will be used in many
ways we cannot yet fathom, but it is important that we are clear in the
uses we have intended the release to fulfill and communicate that well.
I do like the idea of specific downloads that can be run. Tar-balls
are easy to share and distribute, if they come with a simple/common
command to get them up and running according to their vehicle it will
make the use of them all the easier.
Regards,
Chris
On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
As noted on the TSC call, we would really like some input from the
projects and consumers on what Vehicles would be useful. Please speak
up :)
Ed
On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
The TSC needs to figure out what the Simultaneous Release Vehicles
look like.
I've been asked to kick off a conversation here, to garner input
from the community, particularly the various projects, as to what
those should look like.
I suspect we don't want to simply release a 'kitchen sink' with
everything rolled into it, but rather would like to release a
relatively small number (think 3-5) of 'flavors' containing things
that thematically go together.
Examples of how we might proceed (and I am not advocating for
anything here, just pointing out examples to get conversation going)
might be things like:
OpenDaylight Base Edition
OpenDaylight Service Provider Edition OpenDaylight Cloud Edition
Thoughts?
Ed _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________ TSC mailing list TSC@... https://lists.opendaylight.org/mailman/listinfo/tsc
|
|
|
Baohua Yang
Yes Luis, that's what I tried to express, we should find a good balance point. Thanks!
On Fri, Sep 6, 2013 at 10:45 AM, Luis Gomez <luis.gomez@...> wrote:
Do not get me wrong, I think it is very good idea and we should actually allow some degree of customizability to end user but keeping in mind the balance customizability
vs I&V (and later support) effort.
BR/Luis
From: Baohua Yang [mailto:yangbaohua@...]
Sent: Thursday, September 05, 2013 7:18 PM
To: Luis Gomez
Cc: Christopher Price; Ed Warnicke (eaw); discuss@...; tsc@...
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles
That is a little difficult to implement now, however it would be very promising and attractive.
IMHO, good UE (user experience) will be achieved if all trival config/compatible checking is done automatically.
I suggest every official release provide an full-operational platform, based on what high-level apps can be customized accordingly (Not all possible configs, but numbers of).
For example, users can login in ODL's webUI, and through which find a list of available apps, and users can easily install/uninstall by clicking buttons (config file way is alternative). The apps can be maintained by an ODL/rhird-party
source.
As an opensource project, I believe customizability is one principle.
Oh, just wake me up if I ran into a stupid idea. :)
On Fri, Sep 6, 2013 at 10:02 AM, Luis Gomez <luis.gomez@...> wrote:
Sounds very good, however whether or not the “customizable” release will be allowed, from an I&V
point of view we cannot test all the possible configurations…
From: Baohua Yang [mailto:yangbaohua@...]
Sent: Thursday, September 05, 2013 6:56 PM
To: Christopher Price
Cc: Ed Warnicke (eaw);
discuss@...;
tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles
Love the naming.
The three versions are good baseline.
Beside, is it possible to provide a "customizable" release?
Users can selectively build what their need easily, and download app bundles from an "ODL AppStore".
On Fri, Sep 6, 2013 at 3:22 AM, Christopher Price <christopher.price@...> wrote:
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct, and manipulate this proposal in meaningful ways. I have tried to
simplify the basic edition while making it useful, as Ken pointed out, to
ODL users looking to get started. I have also tried to include projects
in only one release vehicle, this may upset some projects as I may be
completely wrong with my placement, so jump in and start correcting the
list (or the way it is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
>Hi All,
>
>Please engage in further discussion on the structure proposed on the TSC
>call, in essence to me at least the proposal makes a lot of sense. We
>don't want too many options and a limited amount of configuration
>parameters etc for the end user.
>
>Some thoughts to add to the proposal:
> The basic package should contain the smallest possible collection of
>functionality.
> (OF and NetConf as potential south bounds with no application functions)
> Other packages should derive from the basic package.
> (Simplification of I&T activity, consistency of packaging)
> The release vehicles should provide targeted deployment solutions
>encompassing each included project.
> (We should not try to overload release vehicles)
>
>Once the rabbit is out of the hat of course it will be used in many ways
>we cannot yet fathom, but it is important that we are clear in the uses we
>have intended the release to fulfill and communicate that well.
>
>I do like the idea of specific downloads that can be run. Tar-balls are
>easy to share and distribute, if they come with a simple/common command to
>get them up and running according to their vehicle it will make the use of
>them all the easier.
>
>Regards,
> Chris
>
>
>
>
>On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
>
>>As noted on the TSC call, we would really like some input from the
>>projects and consumers on
>>what Vehicles would be useful. Please speak up :)
>>
>>Ed
>>On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
>>
>>> Guys,
>>> The TSC needs to figure out what the Simultaneous Release Vehicles
>>>look like.
>>> I've been asked to kick off a conversation here, to garner input from
>>>the community, particularly
>>> the various projects, as to what those should look like.
>>>
>>> I suspect we don't want to simply release a 'kitchen sink' with
>>>everything rolled into it, but
>>> rather would like to release a relatively small number (think 3-5) of
>>>'flavors' containing things
>>> that thematically go together.
>>>
>>> Examples of how we might proceed (and I am not advocating for anything
>>>here, just pointing
>>> out examples to get conversation going) might be things like:
>>>
>>> OpenDaylight Base Edition
>>> OpenDaylight Service Provider Edition
>>> OpenDaylight Cloud Edition
>>>
>>> Thoughts?
>>>
>>> Ed
>>
>>_______________________________________________
>>Discuss mailing list
>>Discuss@...
>>https://lists.opendaylight.org/mailman/listinfo/discuss
>
>_______________________________________________
>Discuss mailing list
>Discuss@...
>https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
--
Best wishes!
Baohua
--
Best wishes!
Baohua
-- Best wishes!
Baohua
|
|
|
Luis Gomez <luis.gomez@...>
Do not get me wrong, I think it is very good idea and we should actually allow some degree of customizability to end user but keeping in mind the balance customizability
vs I&V (and later support) effort.
BR/Luis
toggle quoted message
Show quoted text
From: Baohua Yang [mailto:yangbaohua@...]
Sent: Thursday, September 05, 2013 7:18 PM
To: Luis Gomez
Cc: Christopher Price; Ed Warnicke (eaw); discuss@...; tsc@...
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles
That is a little difficult to implement now, however it would be very promising and attractive.
IMHO, good UE (user experience) will be achieved if all trival config/compatible checking is done automatically.
I suggest every official release provide an full-operational platform, based on what high-level apps can be customized accordingly (Not all possible configs, but numbers of).
For example, users can login in ODL's webUI, and through which find a list of available apps, and users can easily install/uninstall by clicking buttons (config file way is alternative). The apps can be maintained by an ODL/rhird-party
source.
As an opensource project, I believe customizability is one principle.
Oh, just wake me up if I ran into a stupid idea. :)
On Fri, Sep 6, 2013 at 10:02 AM, Luis Gomez <luis.gomez@...> wrote:
Sounds very good, however whether or not the “customizable” release will be allowed, from an I&V
point of view we cannot test all the possible configurations…
From: Baohua Yang [mailto:yangbaohua@...]
Sent: Thursday, September 05, 2013 6:56 PM
To: Christopher Price
Cc: Ed Warnicke (eaw);
discuss@...;
tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles
Love the naming.
The three versions are good baseline.
Beside, is it possible to provide a "customizable" release?
Users can selectively build what their need easily, and download app bundles from an "ODL AppStore".
On Fri, Sep 6, 2013 at 3:22 AM, Christopher Price <christopher.price@...> wrote:
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct, and manipulate this proposal in meaningful ways. I have tried to
simplify the basic edition while making it useful, as Ken pointed out, to
ODL users looking to get started. I have also tried to include projects
in only one release vehicle, this may upset some projects as I may be
completely wrong with my placement, so jump in and start correcting the
list (or the way it is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
>Hi All,
>
>Please engage in further discussion on the structure proposed on the TSC
>call, in essence to me at least the proposal makes a lot of sense. We
>don't want too many options and a limited amount of configuration
>parameters etc for the end user.
>
>Some thoughts to add to the proposal:
> The basic package should contain the smallest possible collection of
>functionality.
> (OF and NetConf as potential south bounds with no application functions)
> Other packages should derive from the basic package.
> (Simplification of I&T activity, consistency of packaging)
> The release vehicles should provide targeted deployment solutions
>encompassing each included project.
> (We should not try to overload release vehicles)
>
>Once the rabbit is out of the hat of course it will be used in many ways
>we cannot yet fathom, but it is important that we are clear in the uses we
>have intended the release to fulfill and communicate that well.
>
>I do like the idea of specific downloads that can be run. Tar-balls are
>easy to share and distribute, if they come with a simple/common command to
>get them up and running according to their vehicle it will make the use of
>them all the easier.
>
>Regards,
> Chris
>
>
>
>
>On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
>
>>As noted on the TSC call, we would really like some input from the
>>projects and consumers on
>>what Vehicles would be useful. Please speak up :)
>>
>>Ed
>>On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
>>
>>> Guys,
>>> The TSC needs to figure out what the Simultaneous Release Vehicles
>>>look like.
>>> I've been asked to kick off a conversation here, to garner input from
>>>the community, particularly
>>> the various projects, as to what those should look like.
>>>
>>> I suspect we don't want to simply release a 'kitchen sink' with
>>>everything rolled into it, but
>>> rather would like to release a relatively small number (think 3-5) of
>>>'flavors' containing things
>>> that thematically go together.
>>>
>>> Examples of how we might proceed (and I am not advocating for anything
>>>here, just pointing
>>> out examples to get conversation going) might be things like:
>>>
>>> OpenDaylight Base Edition
>>> OpenDaylight Service Provider Edition
>>> OpenDaylight Cloud Edition
>>>
>>> Thoughts?
>>>
>>> Ed
>>
>>_______________________________________________
>>Discuss mailing list
>>Discuss@...
>>https://lists.opendaylight.org/mailman/listinfo/discuss
>
>_______________________________________________
>Discuss mailing list
>Discuss@...
>https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
--
Best wishes!
Baohua
--
Best wishes!
Baohua
|
|
|
Baohua Yang
That is a little difficult to implement now, however it would be very promising and attractive. IMHO, good UE (user experience) will be achieved if all trival config/compatible checking is done automatically.
I suggest every official release provide an full-operational platform, based on what high-level apps can be customized accordingly (Not all possible configs, but numbers of). For example, users can login in ODL's webUI, and through which find a list of available apps, and users can easily install/uninstall by clicking buttons (config file way is alternative). The apps can be maintained by an ODL/rhird-party source.
As an opensource project, I believe customizability is one principle. Oh, just wake me up if I ran into a stupid idea. :)
Sounds very good, however whether or not the “customizable” release will be allowed, from an I&V point of view we cannot test all the possible configurations…
From: Baohua Yang [mailto:yangbaohua@...]
Sent: Thursday, September 05, 2013 6:56 PM
To: Christopher Price
Cc: Ed Warnicke (eaw); discuss@...; tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles
Love the naming.
The three versions are good baseline.
Beside, is it possible to provide a "customizable" release?
Users can selectively build what their need easily, and download app bundles from an "ODL AppStore".
On Fri, Sep 6, 2013 at 3:22 AM, Christopher Price <christopher.price@...> wrote:
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct, and manipulate this proposal in meaningful ways. I have tried to
simplify the basic edition while making it useful, as Ken pointed out, to
ODL users looking to get started. I have also tried to include projects
in only one release vehicle, this may upset some projects as I may be
completely wrong with my placement, so jump in and start correcting the
list (or the way it is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
>Hi All,
>
>Please engage in further discussion on the structure proposed on the TSC
>call, in essence to me at least the proposal makes a lot of sense. We
>don't want too many options and a limited amount of configuration
>parameters etc for the end user.
>
>Some thoughts to add to the proposal:
> The basic package should contain the smallest possible collection of
>functionality.
> (OF and NetConf as potential south bounds with no application functions)
> Other packages should derive from the basic package.
> (Simplification of I&T activity, consistency of packaging)
> The release vehicles should provide targeted deployment solutions
>encompassing each included project.
> (We should not try to overload release vehicles)
>
>Once the rabbit is out of the hat of course it will be used in many ways
>we cannot yet fathom, but it is important that we are clear in the uses we
>have intended the release to fulfill and communicate that well.
>
>I do like the idea of specific downloads that can be run. Tar-balls are
>easy to share and distribute, if they come with a simple/common command to
>get them up and running according to their vehicle it will make the use of
>them all the easier.
>
>Regards,
> Chris
>
>
>
>
>On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
>
>>As noted on the TSC call, we would really like some input from the
>>projects and consumers on
>>what Vehicles would be useful. Please speak up :)
>>
>>Ed
>>On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
>>
>>> Guys,
>>> The TSC needs to figure out what the Simultaneous Release Vehicles
>>>look like.
>>> I've been asked to kick off a conversation here, to garner input from
>>>the community, particularly
>>> the various projects, as to what those should look like.
>>>
>>> I suspect we don't want to simply release a 'kitchen sink' with
>>>everything rolled into it, but
>>> rather would like to release a relatively small number (think 3-5) of
>>>'flavors' containing things
>>> that thematically go together.
>>>
>>> Examples of how we might proceed (and I am not advocating for anything
>>>here, just pointing
>>> out examples to get conversation going) might be things like:
>>>
>>> OpenDaylight Base Edition
>>> OpenDaylight Service Provider Edition
>>> OpenDaylight Cloud Edition
>>>
>>> Thoughts?
>>>
>>> Ed
>>
>>_______________________________________________
>>Discuss mailing list
>>Discuss@...
>>https://lists.opendaylight.org/mailman/listinfo/discuss
>
>_______________________________________________
>Discuss mailing list
>Discuss@...
>https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
--
Best wishes!
Baohua
--
Best wishes!
Baohua
|
|
|
Luis Gomez <luis.gomez@...>
Sounds very good, however whether or not the “customizable” release will be allowed, from an I&V point of view we cannot test all the possible configurations…
toggle quoted message
Show quoted text
From: Baohua Yang [mailto:yangbaohua@...]
Sent: Thursday, September 05, 2013 6:56 PM
To: Christopher Price
Cc: Ed Warnicke (eaw); discuss@...; tsc@...; Luis Gomez
Subject: Re: [OpenDaylight TSC] [OpenDaylight Discuss] OpenDaylight Release Vehicles
Love the naming.
The three versions are good baseline.
Beside, is it possible to provide a "customizable" release?
Users can selectively build what their need easily, and download app bundles from an "ODL AppStore".
On Fri, Sep 6, 2013 at 3:22 AM, Christopher Price <christopher.price@...> wrote:
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct, and manipulate this proposal in meaningful ways. I have tried to
simplify the basic edition while making it useful, as Ken pointed out, to
ODL users looking to get started. I have also tried to include projects
in only one release vehicle, this may upset some projects as I may be
completely wrong with my placement, so jump in and start correcting the
list (or the way it is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
>Hi All,
>
>Please engage in further discussion on the structure proposed on the TSC
>call, in essence to me at least the proposal makes a lot of sense. We
>don't want too many options and a limited amount of configuration
>parameters etc for the end user.
>
>Some thoughts to add to the proposal:
> The basic package should contain the smallest possible collection of
>functionality.
> (OF and NetConf as potential south bounds with no application functions)
> Other packages should derive from the basic package.
> (Simplification of I&T activity, consistency of packaging)
> The release vehicles should provide targeted deployment solutions
>encompassing each included project.
> (We should not try to overload release vehicles)
>
>Once the rabbit is out of the hat of course it will be used in many ways
>we cannot yet fathom, but it is important that we are clear in the uses we
>have intended the release to fulfill and communicate that well.
>
>I do like the idea of specific downloads that can be run. Tar-balls are
>easy to share and distribute, if they come with a simple/common command to
>get them up and running according to their vehicle it will make the use of
>them all the easier.
>
>Regards,
> Chris
>
>
>
>
>On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
>
>>As noted on the TSC call, we would really like some input from the
>>projects and consumers on
>>what Vehicles would be useful. Please speak up :)
>>
>>Ed
>>On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
>>
>>> Guys,
>>> The TSC needs to figure out what the Simultaneous Release Vehicles
>>>look like.
>>> I've been asked to kick off a conversation here, to garner input from
>>>the community, particularly
>>> the various projects, as to what those should look like.
>>>
>>> I suspect we don't want to simply release a 'kitchen sink' with
>>>everything rolled into it, but
>>> rather would like to release a relatively small number (think 3-5) of
>>>'flavors' containing things
>>> that thematically go together.
>>>
>>> Examples of how we might proceed (and I am not advocating for anything
>>>here, just pointing
>>> out examples to get conversation going) might be things like:
>>>
>>> OpenDaylight Base Edition
>>> OpenDaylight Service Provider Edition
>>> OpenDaylight Cloud Edition
>>>
>>> Thoughts?
>>>
>>> Ed
>>
>>_______________________________________________
>>Discuss mailing list
>>Discuss@...
>>https://lists.opendaylight.org/mailman/listinfo/discuss
>
>_______________________________________________
>Discuss mailing list
>Discuss@...
>https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
--
Best wishes!
Baohua
|
|
|
Baohua Yang
Love the naming. The three versions are good baseline. Beside, is it possible to provide a "customizable" release? Just like the linux os. Users can selectively build what their need easily, and download app bundles from an "ODL AppStore".
On Fri, Sep 6, 2013 at 3:22 AM, Christopher Price <christopher.price@...> wrote:
So I'm going to throw out a discussion on proposed bundling of
projects/release vehicles.
Please don't beat me for the proposal, but do feel free to discuss,
correct, and manipulate this proposal in meaningful ways. I have tried to
simplify the basic edition while making it useful, as Ken pointed out, to
ODL users looking to get started. I have also tried to include projects
in only one release vehicle, this may upset some projects as I may be
completely wrong with my placement, so jump in and start correcting the
list (or the way it is proposed for that matter).
* OpenDaylight Base Edition
Controller
OpenFlow(s)
Netconf
YangTools*
* OpenDaylight Service Provider Edition
ODL Basic Edition
BGP-LS/PCEP
Defence4All
Lisp Flow Mapping
SNMP4SDN
* OpenDaylight Cloud Edition
ODL Basic Edition
OVSDB
OpenDove
VTN
Affinity Metadata Service
Regards,
Chris
On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...>
wrote:
>Hi All,
>
>Please engage in further discussion on the structure proposed on the TSC
>call, in essence to me at least the proposal makes a lot of sense. We
>don't want too many options and a limited amount of configuration
>parameters etc for the end user.
>
>Some thoughts to add to the proposal:
> The basic package should contain the smallest possible collection of
>functionality.
> (OF and NetConf as potential south bounds with no application functions)
> Other packages should derive from the basic package.
> (Simplification of I&T activity, consistency of packaging)
> The release vehicles should provide targeted deployment solutions
>encompassing each included project.
> (We should not try to overload release vehicles)
>
>Once the rabbit is out of the hat of course it will be used in many ways
>we cannot yet fathom, but it is important that we are clear in the uses we
>have intended the release to fulfill and communicate that well.
>
>I do like the idea of specific downloads that can be run. Tar-balls are
>easy to share and distribute, if they come with a simple/common command to
>get them up and running according to their vehicle it will make the use of
>them all the easier.
>
>Regards,
> Chris
>
>
>
>
>On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" < eaw@...> wrote:
>
>>As noted on the TSC call, we would really like some input from the
>>projects and consumers on
>>what Vehicles would be useful. Please speak up :)
>>
>>Ed
>>On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) < eaw@...> wrote:
>>
>>> Guys,
>>> The TSC needs to figure out what the Simultaneous Release Vehicles
>>>look like.
>>> I've been asked to kick off a conversation here, to garner input from
>>>the community, particularly
>>> the various projects, as to what those should look like.
>>>
>>> I suspect we don't want to simply release a 'kitchen sink' with
>>>everything rolled into it, but
>>> rather would like to release a relatively small number (think 3-5) of
>>>'flavors' containing things
>>> that thematically go together.
>>>
>>> Examples of how we might proceed (and I am not advocating for anything
>>>here, just pointing
>>> out examples to get conversation going) might be things like:
>>>
>>> OpenDaylight Base Edition
>>> OpenDaylight Service Provider Edition
>>> OpenDaylight Cloud Edition
>>>
>>> Thoughts?
>>>
>>> Ed
>>
>>_______________________________________________
>>Discuss mailing list
>> Discuss@...
>> https://lists.opendaylight.org/mailman/listinfo/discuss
>
>_______________________________________________
>Discuss mailing list
> Discuss@...
> https://lists.opendaylight.org/mailman/listinfo/discuss
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
-- Best wishes!
Baohua
|
|
|
Luis Gomez <luis.gomez@...>
Just one more thought: if we go ahead with this proposal, a company providing both Cloud and SP services will need to setup 2 separate controller to run both services. This makes sense to me as they will probably have different people and infrastructure for Cloud and SP services but maybe someone has some concerns.
BR/Luis
toggle quoted message
Show quoted text
-----Original Message----- From: Christopher Price Sent: Thursday, September 05, 2013 12:23 PM To: Christopher Price; Ed Warnicke (eaw); discuss@...; tsc@...; Luis Gomez Subject: Re: [OpenDaylight Discuss] OpenDaylight Release Vehicles So I'm going to throw out a discussion on proposed bundling of projects/release vehicles. Please don't beat me for the proposal, but do feel free to discuss, correct, and manipulate this proposal in meaningful ways. I have tried to simplify the basic edition while making it useful, as Ken pointed out, to ODL users looking to get started. I have also tried to include projects in only one release vehicle, this may upset some projects as I may be completely wrong with my placement, so jump in and start correcting the list (or the way it is proposed for that matter). * OpenDaylight Base Edition Controller OpenFlow(s) Netconf YangTools* * OpenDaylight Service Provider Edition ODL Basic Edition BGP-LS/PCEP Defence4All Lisp Flow Mapping SNMP4SDN * OpenDaylight Cloud Edition ODL Basic Edition OVSDB OpenDove VTN Affinity Metadata Service Regards, Chris On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...> wrote: Hi All,
Please engage in further discussion on the structure proposed on the TSC
call, in essence to me at least the proposal makes a lot of sense. We
don't want too many options and a limited amount of configuration
parameters etc for the end user.
Some thoughts to add to the proposal:
The basic package should contain the smallest possible collection of
functionality.
(OF and NetConf as potential south bounds with no application functions)
Other packages should derive from the basic package.
(Simplification of I&T activity, consistency of packaging)
The release vehicles should provide targeted deployment solutions
encompassing each included project.
(We should not try to overload release vehicles)
Once the rabbit is out of the hat of course it will be used in many ways
we cannot yet fathom, but it is important that we are clear in the uses we
have intended the release to fulfill and communicate that well.
I do like the idea of specific downloads that can be run. Tar-balls are
easy to share and distribute, if they come with a simple/common command to
get them up and running according to their vehicle it will make the use of
them all the easier.
Regards,
Chris
On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
As noted on the TSC call, we would really like some input from the
projects and consumers on
what Vehicles would be useful. Please speak up :)
Ed
On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
The TSC needs to figure out what the Simultaneous Release Vehicles
look like.
I've been asked to kick off a conversation here, to garner input from
the community, particularly
the various projects, as to what those should look like.
I suspect we don't want to simply release a 'kitchen sink' with
everything rolled into it, but
rather would like to release a relatively small number (think 3-5) of
'flavors' containing things
that thematically go together.
Examples of how we might proceed (and I am not advocating for anything
here, just pointing
out examples to get conversation going) might be things like:
OpenDaylight Base Edition
OpenDaylight Service Provider Edition
OpenDaylight Cloud Edition
Thoughts?
Ed _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
|
|
|
Christopher Price <christopher.price@...>
So I'm going to throw out a discussion on proposed bundling of projects/release vehicles. Please don't beat me for the proposal, but do feel free to discuss, correct, and manipulate this proposal in meaningful ways. I have tried to simplify the basic edition while making it useful, as Ken pointed out, to ODL users looking to get started. I have also tried to include projects in only one release vehicle, this may upset some projects as I may be completely wrong with my placement, so jump in and start correcting the list (or the way it is proposed for that matter). * OpenDaylight Base Edition Controller OpenFlow(s) Netconf YangTools* * OpenDaylight Service Provider Edition ODL Basic Edition BGP-LS/PCEP Defence4All Lisp Flow Mapping SNMP4SDN * OpenDaylight Cloud Edition ODL Basic Edition OVSDB OpenDove VTN Affinity Metadata Service Regards, Chris On 9/5/13 12:10 PM, "Christopher Price" <christopher.price@...> wrote: Hi All,
Please engage in further discussion on the structure proposed on the TSC
call, in essence to me at least the proposal makes a lot of sense. We
don't want too many options and a limited amount of configuration
parameters etc for the end user.
Some thoughts to add to the proposal:
The basic package should contain the smallest possible collection of
functionality.
(OF and NetConf as potential south bounds with no application functions)
Other packages should derive from the basic package.
(Simplification of I&T activity, consistency of packaging)
The release vehicles should provide targeted deployment solutions
encompassing each included project.
(We should not try to overload release vehicles)
Once the rabbit is out of the hat of course it will be used in many ways
we cannot yet fathom, but it is important that we are clear in the uses we
have intended the release to fulfill and communicate that well.
I do like the idea of specific downloads that can be run. Tar-balls are
easy to share and distribute, if they come with a simple/common command to
get them up and running according to their vehicle it will make the use of
them all the easier.
Regards,
Chris
On 9/5/13 10:48 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:
As noted on the TSC call, we would really like some input from the
projects and consumers on
what Vehicles would be useful. Please speak up :)
Ed
On Sep 4, 2013, at 12:07 AM, Ed Warnicke (eaw) <eaw@...> wrote:
Guys,
The TSC needs to figure out what the Simultaneous Release Vehicles
look like.
I've been asked to kick off a conversation here, to garner input from
the community, particularly
the various projects, as to what those should look like.
I suspect we don't want to simply release a 'kitchen sink' with
everything rolled into it, but
rather would like to release a relatively small number (think 3-5) of
'flavors' containing things
that thematically go together.
Examples of how we might proceed (and I am not advocating for anything
here, just pointing
out examples to get conversation going) might be things like:
OpenDaylight Base Edition
OpenDaylight Service Provider Edition
OpenDaylight Cloud Edition
Thoughts?
Ed _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss _______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
|
|
|
