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