* 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