Date   

Re: Resolving the multiple controller code bases issue

Ed Warnicke (eaw) <eaw@...>
 

Happy to move to a more reasonable place… suggestions?  Would it make sense to hang them off of:


before the 'OpenDaylight Project Documentation' section?  Elsewhere?

Ed

On Apr 29, 2013, at 3:05 PM, David Meyer <dmm@...> wrote:



On Mon, Apr 29, 2013 at 1:03 PM, Colin Dixon <ckd@...> wrote:

The list of desirable features which you're asking for are at least partially documented here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Architectural_Principles

Presumably we should move that out to a project-neutral space on the wiki and attach it to any discussions as we go forward.


Thanks for pointing this out. For those who haven't taken a look at this page, it has some reasonable principles. Also agree with Colin that these are general principles, not project specific.

--dmm
 



--Colin

tsc-bounces@... wrote on 04/29/2013 02:49:19 PM:
> From: Chris Wright <chrisw@...>

> To: David Meyer <dmm@...>
> Cc: tsc@...
> Date: 04/29/2013 02:49 PM
> Subject: Re: [OpenDaylight TSC] Resolving the multiple controller
> code bases issue

> Sent by: tsc-bounces@...

>
> * David Meyer (dmm@...) wrote:
> > As you may know, there have been several proposals floated to
> > deal with the problems created by the fact that we have two
> > controller code bases. These include but not limited to:
> >
> > (i).    Work on portability between code bases and maintain two
> >         controllers going forward. This would obviously create
> >         enormous challenges and inefficiencies over time. In
> >         addition, it will continue the lack of clarity over
> >         the ODP controller code base.
>
> Agreed, non-starter.
>
> > (ii).   Create a new controller project that would incorporate
> >         the desirable components of both controllers (the
> >         so-called "merged controller"). Note that the creation of
> >         such a third controller project would require extensive
> >         resources for design and integration, versus expanding on
> >         what we already have. Again, such an approach will also
> >         continue the lack of clarity over the ODP controller code
> >         base and push our deliverables out an for an undefined
> >         period of time.
>
> I actually think this is quite similar to or at least a variant of what
> you've outlined in your proposal below.
>
> > (iii).  Have the TSC vote for either the Cisco or BSN code base
> >         as the ODP controller code base. The TSC could also vote
> >         to keep the other code base available in case it ever
> >         wanted to pull parts of the other code base in.
>
> BTW, let's keep this to the projects and their developers.
> So, that is the "controller" project and the "net-virt-platform"
> project.
>
> > (iv).   Others that I might have missed?
> >
> > Clearly neither option (i). nor option (ii). reach the objective
> > of providing a clear understanding for the community of which
> > code base ODP is building on (nor would they do so in a timely
> > fashion). On the other hand, jumping directly to option (iii). is
> > not optimal as we might miss out on compromises that could be
> > beneficial to our community (as well as being more "top-down"
> > than we would like).
> >
> > Since our clear goal (and responsibility) is to make ODP into the
> > standard open source infrastructure for SDN, it is incumbent upon
> > us as the ODP TSC to take affirmative action to clear this
> > problem and get ODP moving. To that end and in consultation with
> > the Linux Foundation and others, I am formally putting the
> > following resolution process in place:
> >
> > (a).    I will ask Cisco and BSN to create a proposal for one
> >         controller code base that comprise the ODP controller
> >         code base. This "one code base" could be either code
> >         bases or a mashup of the two that Cisco and BSN feel,
> >         from a technical point of view, will best serve the ODP
> >         community. In addition, the proposal may include
> >         proposals to start other ODP projects or sub-projects to
> >         address any gaps or future work.  And of course,
> >         community members are encouraged to participate in
> >         this process.
>
> I agree.  Pushing back on the developers that own each proposal and making
> the path forward "their problem" is a tried and true way to try to positively
> engage each of the teams.  A critical component of the success of
> OpenDaylight is building community and collaboration.
>
> > (b).   The proposal should be available for TSC review no later
> >         than Monday, 13 May 2013. Of course, we should provide
> >         for flexibility in the event substantive progress is
> >         being made. That said, 13 May 2013 should be our target
> >         date.
> >
> > (c).    If no proposal can be created by Cisco and BSN (possibly
> >         working with other community members), the TSC will take
> >         an up or down vote on which controller code base ODP will
> >         be using going forward. The vote should be taken on
> >         Tuesday, 14 May 2013 by email in a private ballot to
> >         preclude the appearance of a "deciding vote" being cast
> >         by any TSC member. I propose that the Linux Foundation
> >         receive, tally, and make public all the votes and the
> >         result at the same time.
>
> I believe we'd need to have some metrics that we (the TSC) would be
> using to evaluate the code bases and make a vote that's not completely
> arbitrary or a popularity contest.  Some examples are (just throwing
> things out to be concrete):
>
> 1) controller extensibility and modularity
> 2) model driven API abstraction
> 3) ability to support eventual consistency model
> 4) ability to support multiple southbound plugins
> 5) ability to support virtual networking requirements
>
> And I see this as an absolute last resort.  Basically, if we get here
> it's because the controller and net-virt-platform teams have reached
> some fundamental impasse.
>
> > Note that it is not uncommon for an open source project such as
> > ODP to have competing code bases, nor is it uncommon for a
> > resolution such as described above to be used in these cases. In
> > particular, this process is designed to both be as true as
> > possible to the open source community and its governance model
> > while at the same time providing a forcing function to drive
> > resolution of our controller code base problem.
> >
> > Finally, I have asked Collin Dixon and David Erickson to start a
> > discussion of architectural and technical aspects of the two code
> > bases on discuss@.... Thanks Colin and David!
> > Please join in on that discussion to the extent you have
> > time/inclination. This discussion is a crucial part of building
> > our community, and we will need such an analysis in the event
> > that vote. In particular, this work will give us a technical
> > basis on which to base our votes.
>
> Yes, OK.  Let's use that to build the list I mentioned above.
>
> thanks,
> -chris
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>


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


Re: Resolving the multiple controller code bases issue

Rob Sherwood
 

Hi Dave,

I definitely recognize that there is a lot of pressure (from press, developers, even from ourselves) to show that the daylight community can make progress and produce useful code, but I'm not sure that artificially pushing for a final decision on the controllers (one way or another)---especially in this two weeks time frame---is the right way to do it.  

It's my read that the vast majority of people (users, developers, even a number of TSC members) are trying to come up to speed with _what a controller is_ and what is it supposed to do, before even starting on the harder question of "which code base is a better controller".  More so, while I agree with the rough characterization of your three options ( (i) let two controllers exist indefinitely, (ii) merge the controllers, (iii) vote to pick one), we don't yet even know enough to answer the technical feasibility of these options or which one will net result in the best code.

For example, Colin Dixon and I have been talking about potentially merging controllers at the SAL level.  This would mean in net-virt's perspective that the SAL would look like an application, and from the 'controller' project prospective the net-virt controller would look like a SAL plugin.  I think this approach potentially has legs and would solve a lot of problems (and potentially not even be that much work) but we're going to need some time to investigate it.

Last, if we're concerned about being to produce useful code, I would like to submit that working towards some specific user-facing use-case for Q3 (e.g., a full quantum stack with network virtualization support) is a better goal, both from an impact perspective but also because it's less divisive.

What do other people think about this approach to focus on an user-facing deliverable and run the "which controller" question in parallel?

- Rob
.




On Mon, Apr 29, 2013 at 11:57 AM, David Meyer <dmm@...> wrote:
 
[04/29/2013] 
 
As you may know, there have been several proposals floated to 
deal with the problems created by the fact that we have two 
controller code bases. These include but not limited to:  
 
(i).    Work on portability between code bases and maintain two 
        controllers going forward. This would obviously create 
        enormous challenges and inefficiencies over time. In 
        addition, it will continue the lack of clarity over 
        the ODP controller code base. 
 
(ii).   Create a new controller project that would incorporate 
        the desirable components of both controllers (the 
        so-called "merged controller"). Note that the creation of 
        such a third controller project would require extensive 
        resources for design and integration, versus expanding on 
        what we already have. Again, such an approach will also 
        continue the lack of clarity over the ODP controller code 
        base and push our deliverables out an for an undefined 
        period of time.  
 
(iii).  Have the TSC vote for either the Cisco or BSN code base 
        as the ODP controller code base. The TSC could also vote 
        to keep the other code base available in case it ever 
        wanted to pull parts of the other code base in.   
 
(iv).   Others that I might have missed? 
 
Clearly neither option (i). nor option (ii). reach the objective 
of providing a clear understanding for the community of which 
code base ODP is building on (nor would they do so in a timely  
fashion). On the other hand, jumping directly to option (iii). is 
not optimal as we might miss out on compromises that could be 
beneficial to our community (as well as being more "top-down" 
than we would like). 
 
Since our clear goal (and responsibility) is to make ODP into the 
standard open source infrastructure for SDN, it is incumbent upon 
us as the ODP TSC to take affirmative action to clear this 
problem and get ODP moving. To that end and in consultation with 
the Linux Foundation and others, I am formally putting the 
following resolution process in place:  
 
(a).    I will ask Cisco and BSN to create a proposal for one 
        controller code base that comprise the ODP controller 
        code base. This "one code base" could be either code 
        bases or a mashup of the two that Cisco and BSN feel, 
        from a technical point of view, will best serve the ODP 
        community. In addition, the proposal may include 
        proposals to start other ODP projects or sub-projects to 
        address any gaps or future work.  And of course,
        community members are encouraged to participate in 
        this process.
 
(b).   The proposal should be available for TSC review no later 
        than Monday, 13 May 2013. Of course, we should provide 
        for flexibility in the event substantive progress is 
        being made. That said, 13 May 2013 should be our target 
        date.  
 
(c).    If no proposal can be created by Cisco and BSN (possibly 
        working with other community members), the TSC will take 
        an up or down vote on which controller code base ODP will 
        be using going forward. The vote should be taken on 
        Tuesday, 14 May 2013 by email in a private ballot to 
        preclude the appearance of a "deciding vote" being cast 
        by any TSC member. I propose that the Linux Foundation 
        receive, tally, and make public all the votes and the 
        result at the same time.    
 
 
Note that it is not uncommon for an open source project such as 
ODP to have competing code bases, nor is it uncommon for a 
resolution such as described above to be used in these cases. In 
particular, this process is designed to both be as true as 
possible to the open source community and its governance model 
while at the same time providing a forcing function to drive 
resolution of our controller code base problem. 
 
Finally, I have asked Collin Dixon and David Erickson to start a 
discussion of architectural and technical aspects of the two code 
bases on discuss@.... Thanks Colin and David!  
Please join in on that discussion to the extent you have 
time/inclination. This discussion is a crucial part of building 
our community, and we will need such an analysis in the event 
that vote. In particular, this work will give us a technical 
basis on which to base our votes. 
 
Thnx, 
 
--dmm 
 

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



Re: Resolving the multiple controller code bases issue

David Meyer <dmm@...>
 



On Mon, Apr 29, 2013 at 3:10 PM, Rob Sherwood <rob.sherwood@...> wrote:
Hi Dave,

I definitely recognize that there is a lot of pressure (from press, developers, even from ourselves) to show that the daylight community can make progress and produce useful code, but I'm not sure that artificially pushing for a final decision on the controllers (one way or another)---especially in this two weeks time frame---is the right way to do it.  

It time frames are the problem, those can be adjusted. As I mentioned it is more important that we make progress in a timely fashion than the actual date of this or that (at least until we get to delivery schedules).
 

It's my read that the vast majority of people (users, developers, even a number of TSC members) are trying to come up to speed with _what a controller is_ and what is it supposed to do, before even starting on the harder question of "which code base is a better controller".  More so, while I agree with the rough characterization of your three options ( (i) let two controllers exist indefinitely, (ii) merge the controllers, (iii) vote to pick one), we don't yet even know enough to answer the technical feasibility of these options or which one will net result in the best code.

What I'm asking people (such as Colin and David (E)) to do to look at just this. As Chris pointed out,
during the process we'll want to generate metrics (loosely defined) that will allow us to more objectively evaluate our options (we need this as a community in any event). 

For example, Colin Dixon and I have been talking about potentially merging controllers at the SAL level.  This would mean in net-virt's perspective that the SAL would look like an application, and from the 'controller' project prospective the net-virt controller would look like a SAL plugin.  I think this approach potentially has legs and would solve a lot of problems (and potentially not even be that much work) but we're going to need some time to investigate it.

Last, if we're concerned about being to produce useful code, I would like to submit that working towards some specific user-facing use-case for Q3 (e.g., a full quantum stack with network virtualization support) is a better goal, both from an impact perspective but also because it's less divisive.

What do other people think about this approach to focus on an user-facing deliverable and run the "which controller" question in parallel?

While having other (user-facing)  deliverables is goodness (and IMO ultimately where a lot of value will be created) , the problem that I want to solve is to have a stable controller base for such applications to be built on. So it is critical that we sort that out for all the reasons you mention above (and others), and is the problem I intend to address with the process I outlined. In fact, having a stable controller base (including how ever the NB is done, model driven/BigDB/...) would seem to be an obvious prerequisite for the example you cite.

All of that said, if the time frame isn't reasonable (understanding that I was being intentionally aggressive with the two week time frame), let's settle on a reasonable time frame. As I mentioned, making progress is most important but it is also important that we do so in a timely fashion.

--dmm


- Rob
.




On Mon, Apr 29, 2013 at 11:57 AM, David Meyer <dmm@...> wrote:
 
[04/29/2013] 
 
As you may know, there have been several proposals floated to 
deal with the problems created by the fact that we have two 
controller code bases. These include but not limited to:  
 
(i).    Work on portability between code bases and maintain two 
        controllers going forward. This would obviously create 
        enormous challenges and inefficiencies over time. In 
        addition, it will continue the lack of clarity over 
        the ODP controller code base. 
 
(ii).   Create a new controller project that would incorporate 
        the desirable components of both controllers (the 
        so-called "merged controller"). Note that the creation of 
        such a third controller project would require extensive 
        resources for design and integration, versus expanding on 
        what we already have. Again, such an approach will also 
        continue the lack of clarity over the ODP controller code 
        base and push our deliverables out an for an undefined 
        period of time.  
 
(iii).  Have the TSC vote for either the Cisco or BSN code base 
        as the ODP controller code base. The TSC could also vote 
        to keep the other code base available in case it ever 
        wanted to pull parts of the other code base in.   
 
(iv).   Others that I might have missed? 
 
Clearly neither option (i). nor option (ii). reach the objective 
of providing a clear understanding for the community of which 
code base ODP is building on (nor would they do so in a timely  
fashion). On the other hand, jumping directly to option (iii). is 
not optimal as we might miss out on compromises that could be 
beneficial to our community (as well as being more "top-down" 
than we would like). 
 
Since our clear goal (and responsibility) is to make ODP into the 
standard open source infrastructure for SDN, it is incumbent upon 
us as the ODP TSC to take affirmative action to clear this 
problem and get ODP moving. To that end and in consultation with 
the Linux Foundation and others, I am formally putting the 
following resolution process in place:  
 
(a).    I will ask Cisco and BSN to create a proposal for one 
        controller code base that comprise the ODP controller 
        code base. This "one code base" could be either code 
        bases or a mashup of the two that Cisco and BSN feel, 
        from a technical point of view, will best serve the ODP 
        community. In addition, the proposal may include 
        proposals to start other ODP projects or sub-projects to 
        address any gaps or future work.  And of course,
        community members are encouraged to participate in 
        this process.
 
(b).   The proposal should be available for TSC review no later 
        than Monday, 13 May 2013. Of course, we should provide 
        for flexibility in the event substantive progress is 
        being made. That said, 13 May 2013 should be our target 
        date.  
 
(c).    If no proposal can be created by Cisco and BSN (possibly 
        working with other community members), the TSC will take 
        an up or down vote on which controller code base ODP will 
        be using going forward. The vote should be taken on 
        Tuesday, 14 May 2013 by email in a private ballot to 
        preclude the appearance of a "deciding vote" being cast 
        by any TSC member. I propose that the Linux Foundation 
        receive, tally, and make public all the votes and the 
        result at the same time.    
 
 
Note that it is not uncommon for an open source project such as 
ODP to have competing code bases, nor is it uncommon for a 
resolution such as described above to be used in these cases. In 
particular, this process is designed to both be as true as 
possible to the open source community and its governance model 
while at the same time providing a forcing function to drive 
resolution of our controller code base problem. 
 
Finally, I have asked Collin Dixon and David Erickson to start a 
discussion of architectural and technical aspects of the two code 
bases on discuss@.... Thanks Colin and David!  
Please join in on that discussion to the extent you have 
time/inclination. This discussion is a crucial part of building 
our community, and we will need such an analysis in the event 
that vote. In particular, this work will give us a technical 
basis on which to base our votes. 
 
Thnx, 
 
--dmm 
 

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




Re: Resolving the multiple controller code bases issue

Chris Wright <chrisw@...>
 

* Rob Sherwood (rob.sherwood@...) wrote:
I definitely recognize that there is a lot of pressure (from press,
developers, even from ourselves) to show that the daylight community can
make progress and produce useful code, but I'm not sure that artificially
pushing for a final decision on the controllers (one way or
another)---especially in this two weeks time frame---is the right way to do
it.

It's my read that the vast majority of people (users, developers, even a
number of TSC members) are trying to come up to speed with _what a
controller is_ and what is it supposed to do, before even starting on the
harder question of "which code base is a better controller". More so,
while I agree with the rough characterization of your three options ( (i)
let two controllers exist indefinitely, (ii) merge the controllers, (iii)
vote to pick one), we don't yet even know enough to answer the technical
feasibility of these options or which one will net result in the best code.
The problem we have right now is no clear path forward to a single core
code base. As a consequence, we can't really even point would-be users
or developers to a place to go to help us push down that path.

For example, Colin Dixon and I have been talking about potentially merging
controllers at the SAL level. This would mean in net-virt's perspective
that the SAL would look like an application, and from the 'controller'
project prospective the net-virt controller would look like a SAL plugin.

I think this approach potentially has legs and would solve a lot of
problems (and potentially not even be that much work) but we're going to
need some time to investigate it.
Sounds like an excellent thing to get to discuss@ asap. We should
be operating in post early, post often mode. I'd particularly like
to understand (not here, but on the proper list), how this actually
concentrates our effort.

Last, if we're concerned about being to produce useful code, I would like
to submit that working towards some specific user-facing use-case for Q3
(e.g., a full quantum stack with network virtualization support) is a
better goal, both from an impact perspective but also because it's less
divisive.
How is it less divisive? And how does doing it in parallel help focus
our effort?

thanks,
-chris


Re: Increasing TSC meetings to twice per week

Rob Sherwood
 

Did we settle on something here?  If so, I didn't see it.  My pref would be to extend our existing meeting rather than have another one, because we always loose time trying to make sure everyone is on the call, etc.  That said, I can move most things on Tuesday except my 10-11a (ONF Council of Chairs meeting).

Thanks,

- Rob
.


On Fri, Apr 26, 2013 at 10:54 AM, Christopher Price <christopher.price@...> wrote:
Hi Phil,

In general Tuesdays work for me I don't have anything recurring that cannot be shuffled.

/ Chris

From: Phil Robb <probb@...>
Date: Thursday, April 25, 2013 7:15 PM

To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Increasing TSC meetings to twice per week

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Alternatively we could expand the meeting on Thursdays to 2 hours.

Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb

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



Re: Increasing TSC meetings to twice per week

David Meyer <dmm@...>
 



On Tue, Apr 30, 2013 at 8:10 AM, Rob Sherwood <rob.sherwood@...> wrote:
Did we settle on something here?  If so, I didn't see it.  My pref would be to extend our existing meeting rather than have another one, because we always loose time trying to make sure everyone is on the call, etc.  That said, I can move most things on Tuesday except my 10-11a (ONF Council of Chairs meeting).

Rob, we haven't closed on this yet but I have put it on the agenda for Thursday (which should be posted today (RSN)). --dmm
 

Thanks,

- Rob
.


On Fri, Apr 26, 2013 at 10:54 AM, Christopher Price <christopher.price@...> wrote:
Hi Phil,

In general Tuesdays work for me I don't have anything recurring that cannot be shuffled.

/ Chris

From: Phil Robb <probb@...>
Date: Thursday, April 25, 2013 7:15 PM

To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Increasing TSC meetings to twice per week

Hello OpenDaylight TSC Members:

As Dave mentioned in a previous mail, the TSC is not making as much progress as is needed during the weekly calls that are occurring.  While the discussions and exchange of ideas are excellent,  we are routinely not getting through the agenda which is resulting in items being repeatedly deferred from one week to the next.

We suggest that the TSC add another hour onto our weekly schedules to overcome this increased start-up workload.  We can drop back down to weekly meetings once we are through this initial push.

I would like to suggest that we add a meeting from 10:00am to 11:00am on Tuesday mornings in addition to the one hour (10:00am - 11:00am Thursdays) meetings already scheduled.

Alternatively we could expand the meeting on Thursdays to 2 hours.

Please let me know if you could accomodate a 10am PDT meeting on Tuesdays.  Your help in this is greatly appreciated.  As everyone knows. we have much to get done before our first release in September.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
Skype: Phil.Robb

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



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



Invitation to WebEx meeting: OpenDaylight TSC Meeting

Phil Robb
 

Cisco WebEx logo
Hi,
 
Phil Robb is inviting you to this WebEx meeting:
  
OpenDaylight TSC Meeting

Thu, May 2, 11:00 am | 1 hr

Denver (Mountain Daylight Time, GMT-06:00)

Host: Phil Robb

  
 

Add the attached iCalendar (.ics) file to your calendar.

 

Agenda

This meeting does not have an agenda.
 

Access Information

Where:  WebEx Online
Meeting number:  191 351 304
Password:  This meeting does not require a password.
 

Audio Connection

1-855-244-8681 Call-in toll-free number (US/Canada)

1-650-479-3207 Call-in toll number (US/Canada)

Access code: 191 351 304

Need more numbers or information? Check out toll-free calling restrictions.

 

Meeting Files (0)

Can't access your meeting? Get help.
Delivering the power of collaboration,
Cisco WebEx Team
Footer
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the meeting to be recorded. By joining this meeting, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.

©2013 Cisco and/or its affiliates. All rights reserved.
MT-A-001
Cisco


Re: Resolving the multiple controller code bases issue

David Meyer <dmm@...>
 



On Mon, Apr 29, 2013 at 1:57 PM, Ed Warnicke (eaw) <eaw@...> wrote:
Happy to move to a more reasonable place… suggestions?  Would it make sense to hang them off of:


before the 'OpenDaylight Project Documentation' section?  Elsewhere?

Maybe make a "Core Architectural Principles" or similar after Hackfests (so it would be # 5). Then link your's off that? That way we have a place we can perhaps have discussions around this or other pages. 

Comments?

--dmm


Ed

On Apr 29, 2013, at 3:05 PM, David Meyer <dmm@...> wrote:



On Mon, Apr 29, 2013 at 1:03 PM, Colin Dixon <ckd@...> wrote:

The list of desirable features which you're asking for are at least partially documented here:
https://wiki.opendaylight.org/view/OpenDaylight_Controller:Architectural_Principles

Presumably we should move that out to a project-neutral space on the wiki and attach it to any discussions as we go forward.


Thanks for pointing this out. For those who haven't taken a look at this page, it has some reasonable principles. Also agree with Colin that these are general principles, not project specific.

--dmm
 



--Colin

tsc-bounces@... wrote on 04/29/2013 02:49:19 PM:
> From: Chris Wright <chrisw@...>

> To: David Meyer <dmm@...>
> Cc: tsc@...
> Date: 04/29/2013 02:49 PM
> Subject: Re: [OpenDaylight TSC] Resolving the multiple controller
> code bases issue

> Sent by: tsc-bounces@...

>
> * David Meyer (dmm@...) wrote:
> > As you may know, there have been several proposals floated to
> > deal with the problems created by the fact that we have two
> > controller code bases. These include but not limited to:
> >
> > (i).    Work on portability between code bases and maintain two
> >         controllers going forward. This would obviously create
> >         enormous challenges and inefficiencies over time. In
> >         addition, it will continue the lack of clarity over
> >         the ODP controller code base.
>
> Agreed, non-starter.
>
> > (ii).   Create a new controller project that would incorporate
> >         the desirable components of both controllers (the
> >         so-called "merged controller"). Note that the creation of
> >         such a third controller project would require extensive
> >         resources for design and integration, versus expanding on
> >         what we already have. Again, such an approach will also
> >         continue the lack of clarity over the ODP controller code
> >         base and push our deliverables out an for an undefined
> >         period of time.
>
> I actually think this is quite similar to or at least a variant of what
> you've outlined in your proposal below.
>
> > (iii).  Have the TSC vote for either the Cisco or BSN code base
> >         as the ODP controller code base. The TSC could also vote
> >         to keep the other code base available in case it ever
> >         wanted to pull parts of the other code base in.
>
> BTW, let's keep this to the projects and their developers.
> So, that is the "controller" project and the "net-virt-platform"
> project.
>
> > (iv).   Others that I might have missed?
> >
> > Clearly neither option (i). nor option (ii). reach the objective
> > of providing a clear understanding for the community of which
> > code base ODP is building on (nor would they do so in a timely
> > fashion). On the other hand, jumping directly to option (iii). is
> > not optimal as we might miss out on compromises that could be
> > beneficial to our community (as well as being more "top-down"
> > than we would like).
> >
> > Since our clear goal (and responsibility) is to make ODP into the
> > standard open source infrastructure for SDN, it is incumbent upon
> > us as the ODP TSC to take affirmative action to clear this
> > problem and get ODP moving. To that end and in consultation with
> > the Linux Foundation and others, I am formally putting the
> > following resolution process in place:
> >
> > (a).    I will ask Cisco and BSN to create a proposal for one
> >         controller code base that comprise the ODP controller
> >         code base. This "one code base" could be either code
> >         bases or a mashup of the two that Cisco and BSN feel,
> >         from a technical point of view, will best serve the ODP
> >         community. In addition, the proposal may include
> >         proposals to start other ODP projects or sub-projects to
> >         address any gaps or future work.  And of course,
> >         community members are encouraged to participate in
> >         this process.
>
> I agree.  Pushing back on the developers that own each proposal and making
> the path forward "their problem" is a tried and true way to try to positively
> engage each of the teams.  A critical component of the success of
> OpenDaylight is building community and collaboration.
>
> > (b).   The proposal should be available for TSC review no later
> >         than Monday, 13 May 2013. Of course, we should provide
> >         for flexibility in the event substantive progress is
> >         being made. That said, 13 May 2013 should be our target
> >         date.
> >
> > (c).    If no proposal can be created by Cisco and BSN (possibly
> >         working with other community members), the TSC will take
> >         an up or down vote on which controller code base ODP will
> >         be using going forward. The vote should be taken on
> >         Tuesday, 14 May 2013 by email in a private ballot to
> >         preclude the appearance of a "deciding vote" being cast
> >         by any TSC member. I propose that the Linux Foundation
> >         receive, tally, and make public all the votes and the
> >         result at the same time.
>
> I believe we'd need to have some metrics that we (the TSC) would be
> using to evaluate the code bases and make a vote that's not completely
> arbitrary or a popularity contest.  Some examples are (just throwing
> things out to be concrete):
>
> 1) controller extensibility and modularity
> 2) model driven API abstraction
> 3) ability to support eventual consistency model
> 4) ability to support multiple southbound plugins
> 5) ability to support virtual networking requirements
>
> And I see this as an absolute last resort.  Basically, if we get here
> it's because the controller and net-virt-platform teams have reached
> some fundamental impasse.
>
> > Note that it is not uncommon for an open source project such as
> > ODP to have competing code bases, nor is it uncommon for a
> > resolution such as described above to be used in these cases. In
> > particular, this process is designed to both be as true as
> > possible to the open source community and its governance model
> > while at the same time providing a forcing function to drive
> > resolution of our controller code base problem.
> >
> > Finally, I have asked Collin Dixon and David Erickson to start a
> > discussion of architectural and technical aspects of the two code
> > bases on discuss@.... Thanks Colin and David!
> > Please join in on that discussion to the extent you have
> > time/inclination. This discussion is a crucial part of building
> > our community, and we will need such an analysis in the event
> > that vote. In particular, this work will give us a technical
> > basis on which to base our votes.
>
> Yes, OK.  Let's use that to build the list I mentioned above.
>
> thanks,
> -chris
> _______________________________________________
> TSC mailing list
> TSC@...
> https://lists.opendaylight.org/mailman/listinfo/tsc
>


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



Reminder: TSC call today at 1000 PDT

David Meyer <dmm@...>
 

See https://wiki.opendaylight.org/view/TSC:Main for call information, agenda, and the like.

Thnx,

--dmm


motions and voting

Chris Wright <chrisw@...>
 

I like the way this is handled in the OpenStack Technical Committee:

Motions

Before being put to a vote, motions presented before the TC should be
discussed publicly on the development mailing-list for a minimum of 4
business days to give a chance to the wider community to express their
opinion. TC members can vote positively, negatively, or abstain.
Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).

https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee


Re: motions and voting

Rob Sherwood
 

I would be in favor of instituting wording to this effect.  Thanks Chris for bringing this up.


On Thu, May 2, 2013 at 10:26 AM, Chris Wright <chrisw@...> wrote:
I like the way this is handled in the OpenStack Technical Committee:

  Motions

  Before being put to a vote, motions presented before the TC should be
  discussed publicly on the development mailing-list for a minimum of 4
  business days to give a chance to the wider community to express their
  opinion. TC members can vote positively, negatively, or abstain.
  Decisions need more positive votes than negative votes (ties mean the
  motion is rejected), and a minimum of positive votes of at least one
  third of the total number of TC members (rounded up: in a board with
  8PTLs+5 that means a minimum of 5 approvers).

https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee

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


project names

Chris Wright <chrisw@...>
 

I've been meaning to bring this up for some time now...

I believe we should establish some guidelines on project names.
The current bootstrap projects have named themselves in ways
that are not appropriate and create confusion.

The code under "controller" project is named "OpenDaylight Controller."
The code under "net-virt-platform" project is named "OpenDaylight SDN
Controller Platform." While those projects may aspire towards those
names, they haven't, IMO, earned those names yet.

I suggest that names should be more like codenames (with appropriate
trademark vetting still done).

I suggest that the current names be changed to reflect the above
sentiment.

I suggest that the project lifecycle document be updated to take this
into account. Perhaps as part of Graduation review, we'd allocate a
ODP-wide name that's no longer just the code name.

So, for example, we'd have proposal named HotSidewalk, which upon Graduation
(based on it's functionality) becomes OpenDaylight EggFryer.

Thoughts?

thanks,
-chris


Re: project names

Benson Schliesser <bensons@...>
 

Chris -

This makes sense to me. One question about implementation: who/what is the naming authority for projects? Would the project proposal suggest their own name, or would the name be assigned to a project? In either case, I think the TSC would be responsible for ensuring that project names comply with the spirit of your proposal.

Cheers,
-Benson

On 5/2/13 2:39 PM, Chris Wright wrote:
I've been meaning to bring this up for some time now...

I believe we should establish some guidelines on project names.
The current bootstrap projects have named themselves in ways
that are not appropriate and create confusion.

The code under "controller" project is named "OpenDaylight Controller."
The code under "net-virt-platform" project is named "OpenDaylight SDN
Controller Platform." While those projects may aspire towards those
names, they haven't, IMO, earned those names yet.

I suggest that names should be more like codenames (with appropriate
trademark vetting still done).

I suggest that the current names be changed to reflect the above
sentiment.

I suggest that the project lifecycle document be updated to take this
into account. Perhaps as part of Graduation review, we'd allocate a
ODP-wide name that's no longer just the code name.

So, for example, we'd have proposal named HotSidewalk, which upon Graduation
(based on it's functionality) becomes OpenDaylight EggFryer.

Thoughts?

thanks,
-chris
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Re: OpenDaylight TSC] project names

David Meyer <dmm@...>
 


Chris,

>> I've been meaning to bring this up for some time now...

>> 
>> I believe we should establish some guidelines on project names.
>> The current bootstrap projects have named themselves in ways
>> that are not appropriate and create confusion.

Thank you for raising this. I too have been thinking about this for some time now and came to similar conclusions.

>> The code under "controller" project is named "OpenDaylight Controller."
>> The code under "net-virt-platform" project is named "OpenDaylight SDN
>> Controller Platform."  While those projects may aspire towards those
>> names, they haven't, IMO, earned those names yet.
>> 
>> I suggest that names should be more like codenames (with appropriate
>> trademark vetting still done).
>> 
>> I suggest that the current names be changed to reflect the above
>> sentiment.
>> 
>> I suggest that the project lifecycle document be updated to take this
>> into account.  Perhaps as part of Graduation review, we'd allocate a
>> ODP-wide name that's no longer just the code name.
>> 
>> So, for example, we'd have proposal named HotSidewalk, which upon Graduation
>> (based on it's functionality) becomes OpenDaylight EggFryer.
>> 
>> Thoughts?

I agree. However,  this does suggest that we need a way to manage names, both initially and after Graduation. As you suggest this should likely be part of the lifecycle document. Others?

--dmm


Re: project names

Chris Wright <chrisw@...>
 

* Benson Schliesser (bensons@...) wrote:
This makes sense to me. One question about implementation: who/what is the
naming authority for projects? Would the project proposal suggest their own
name, or would the name be assigned to a project? In either case, I think
the TSC would be responsible for ensuring that project names comply with the
spirit of your proposal.
The initial project proposal comes with a name of their choosing that
must comply w/ our TBD guidelines (for example, not calling yourself
"OpenDaylight *" and perhaps not using obviously generic terms that
simply describe what project does).

The ODP-wide name, which is likely of the form OpenDaylight GenericTerm,
I'd open up defining GenericTerm to the wider community.

thanks,
-chris


Re: project names

Thomas Nadeau <tnadeau@...>
 

That is the TSC with a proposed name from the project proposer, if you
ask me.
In principle, the TSC would keep the naming consistent.

--Tom

On 5/2/13 2:49 PM, "Benson Schliesser" <bensons@...> wrote:

Chris -

This makes sense to me. One question about implementation: who/what is
the naming authority for projects? Would the project proposal suggest
their own name, or would the name be assigned to a project? In either
case, I think the TSC would be responsible for ensuring that project
names comply with the spirit of your proposal.

Cheers,
-Benson


On 5/2/13 2:39 PM, Chris Wright wrote:
I've been meaning to bring this up for some time now...

I believe we should establish some guidelines on project names.
The current bootstrap projects have named themselves in ways
that are not appropriate and create confusion.

The code under "controller" project is named "OpenDaylight Controller."
The code under "net-virt-platform" project is named "OpenDaylight SDN
Controller Platform." While those projects may aspire towards those
names, they haven't, IMO, earned those names yet.

I suggest that names should be more like codenames (with appropriate
trademark vetting still done).

I suggest that the current names be changed to reflect the above
sentiment.

I suggest that the project lifecycle document be updated to take this
into account. Perhaps as part of Graduation review, we'd allocate a
ODP-wide name that's no longer just the code name.

So, for example, we'd have proposal named HotSidewalk, which upon
Graduation
(based on it's functionality) becomes OpenDaylight EggFryer.

Thoughts?

thanks,
-chris
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Re: OpenDaylight TSC] project names

Thomas Nadeau <tnadeau@...>
 



From: David Meyer <dmm@...>
Date: Thursday, May 2, 2013 2:51 PM
To: "tsc@..." <tsc@...>
Subject: Re: [OpenDaylight TSC] OpenDaylight TSC] project names


Chris,

>> I've been meaning to bring this up for some time now...

>> 
>> I believe we should establish some guidelines on project names.
>> The current bootstrap projects have named themselves in ways
>> that are not appropriate and create confusion.

Thank you for raising this. I too have been thinking about this for some time now and came to similar conclusions.

>> The code under "controller" project is named "OpenDaylight Controller."
>> The code under "net-virt-platform" project is named "OpenDaylight SDN
>> Controller Platform."  While those projects may aspire towards those
>> names, they haven't, IMO, earned those names yet.
>> 
>> I suggest that names should be more like codenames (with appropriate
>> trademark vetting still done).
>> 
>> I suggest that the current names be changed to reflect the above
>> sentiment.
>> 
>> I suggest that the project lifecycle document be updated to take this
>> into account.  Perhaps as part of Graduation review, we'd allocate a
>> ODP-wide name that's no longer just the code name.
>> 
>> So, for example, we'd have proposal named HotSidewalk, which upon Graduation
>> (based on it's functionality) becomes OpenDaylight EggFryer.
>> 
>> Thoughts?

I agree. However,  this does suggest that we need a way to manage names, both initially and after Graduation. As you suggest this should likely be part of the lifecycle document. Others?

Agree. The names should perhaps indicate their status too (I.e.: bootstrap, etc…).  

We should also make sure that project names, and any internal object naming is stripped of any commercially named or licensed names to avoid the obvious issues. I think that is specified in the governing documents, but its ultimately up to the TSC to enforce this policy. 

--Tom



Re: project names

Ed Warnicke (eaw) <eaw@...>
 

Benson,

The Project Lifecycle already includes this in the proposal. Clearly a naming problem (for example a trademark or branding or other issue) would preclude acceptance of the proposal until it could be resolved.


Ed

On May 2, 2013, at 1:49 PM, "Benson Schliesser" <bensons@...> wrote:

Chris -

This makes sense to me. One question about implementation: who/what is the naming authority for projects? Would the project proposal suggest their own name, or would the name be assigned to a project? In either case, I think the TSC would be responsible for ensuring that project names comply with the spirit of your proposal.

Cheers,
-Benson


On 5/2/13 2:39 PM, Chris Wright wrote:
I've been meaning to bring this up for some time now...

I believe we should establish some guidelines on project names.
The current bootstrap projects have named themselves in ways
that are not appropriate and create confusion.

The code under "controller" project is named "OpenDaylight Controller."
The code under "net-virt-platform" project is named "OpenDaylight SDN
Controller Platform." While those projects may aspire towards those
names, they haven't, IMO, earned those names yet.

I suggest that names should be more like codenames (with appropriate
trademark vetting still done).

I suggest that the current names be changed to reflect the above
sentiment.

I suggest that the project lifecycle document be updated to take this
into account. Perhaps as part of Graduation review, we'd allocate a
ODP-wide name that's no longer just the code name.

So, for example, we'd have proposal named HotSidewalk, which upon Graduation
(based on it's functionality) becomes OpenDaylight EggFryer.

Thoughts?

thanks,
-chris
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Re: project names

Rob Sherwood
 

Fwiw, I'm very supportive of this with the caveat that it may hard to find neutral names for things and we may need to open it up to suggestions.  Maybe using some sort of prefix like "boostrap-controller-1" and "bootstrap-controller-2"?  

I'm sure that this could be a long conversation, but fundamentally I agree with Chris's point.

- Rob
.


On Thu, May 2, 2013 at 11:39 AM, Chris Wright <chrisw@...> wrote:
I've been meaning to bring this up for some time now...

I believe we should establish some guidelines on project names.
The current bootstrap projects have named themselves in ways
that are not appropriate and create confusion.

The code under "controller" project is named "OpenDaylight Controller."
The code under "net-virt-platform" project is named "OpenDaylight SDN
Controller Platform."  While those projects may aspire towards those
names, they haven't, IMO, earned those names yet.

I suggest that names should be more like codenames (with appropriate
trademark vetting still done).

I suggest that the current names be changed to reflect the above
sentiment.

I suggest that the project lifecycle document be updated to take this
into account.  Perhaps as part of Graduation review, we'd allocate a
ODP-wide name that's no longer just the code name.

So, for example, we'd have proposal named HotSidewalk, which upon Graduation
(based on it's functionality) becomes OpenDaylight EggFryer.

Thoughts?

thanks,
-chris
_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc


Question about Controller Project's Modules/Bundles and Interfaces Page

Aleksandar Miljusevic
 

Hello all,

Is editing of the Controller Project's Modules/Bundles and Interfaces Page going to be open to the public at some point?

Aleksandar Miljusevic

81 - 100 of 14350