The list of desirable features which you're asking for are at least partially documented here:
Presumably we should move that out to a project-neutral space on the wiki and attach it to any discussions as we go forward.
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"
> > (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.
> TSC mailing list