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