[OpenDaylight TSC] board requests of the TSC

Colin Dixon colin at colindixon.com
Tue Mar 31 18:18:50 UTC 2015

Chris, I think you more or less got the gist of what was intended.

I think, by far the most productive thing for the TSC to do is to view this
as a set of goals I think everyone can get behind—with the possible
exception of the last point about small set (ideally one) set of
projects/technologies—and figure out the most expedient way we can get
there while remaining true to the bottom-up culture we have so far.

I (and I'm pretty sure others as well) have been thinking about a lot of
these issues since before any requests came from the board and we should
just use this as a convenient time to make progress on a few fronts.

Some ideas that might make sense to the TSC are:

1.) Requiring projects to have well-defined metrics, code/tests to compute
those metrics, and targets for the metrics for each of security, stability,
scalability and performance in order to graduate to a mature (or higher)
lifecycle state. As part of this, there should be a period of public
comment from the community on the metrics.

2.) As far as baseline components, I'm just going to come out and say that
I think the absolute kernel of OpenDaylight at the moment is (parts of) the
odlparent, yangtools, controller and aaa projects. These are the projects
that every other project (at least in the Lithium release) depend on for
base functionality. Obviously, we shouldn't set this in stone and should
re-evaluate things as necessary. Acknowledging that there is a kernel and
acting appropriately makes sense, but it's already something we do with
offset 0 projects in Lithium. The aaa project isn't an offset 0 project,
but likely should be. We could consider requiring or encouraging these
projects to move to mature in Beryllium.

3.) Beyond this kernel, there are "important" projects (I'm open to other
names) that you can run an OpenDaylight project without, but which are
still critical to the overall OpenDaylight ecosystem. The
openflow{plugin,java} projects are great examples. Figuring out what to do
with "important" projects is something we need to consider. It's clear that
the board would like to see us apply the same logic as things in the
kernel. That might make sense. Certainly having them have metrics as in 1
above seems to make sense to me.

4.) In the context of the first 3 points, it might be instructive for us to
think about logical sub-projects (maybe as defined by a subset of the
projects' karaf features) rather than whole projects as most projects
(especially ones in offset 0) have many different components some of which
are very mature, e.g., yantools java code generation, while others are very

5.) In terms of use cases, I'd like to see them chose in a more bottom up
fashion in the future even though I actually think the two specified use
cases make a lot of sense. I put out some very basic ideas in the "Use Case
Pipeline" presentation I sent out last week. You can see that attached to
this e-mail:


On Thu, Mar 26, 2015 at 2:54 PM, Luis Gomez <ecelgp at gmail.com> wrote:

> Hi Chris,
> Without entering in the format (I always prefer straight talking than
> formal talking) I think you summarized very well what the Board tries to
> communicate to the TSC and the community. I do not know if because of the
> format I heard people screaming on things that IMHO we should be doing in
> the TSC for long time. As lets be honest here, I like the bottom-top
> approach but can anyone tell how many committers and PTLs in ODL have
> scalability, stability, security and performance, uses cases or become
> mature at the top of the priority list? I can give example if asked of perf
> bugs sitting in queues for months and I do not blame projects but TSC
> (specially myself) for not pushing this enough.
> BR/Luis
> On Mar 26, 2015, at 11:51 AM, Chris Price <chrispriceab at gmail.com> wrote:
> Hi Colin,
> Let’s kick off the follow up discussion from the TSC call:
> While much of this e-mail discussed activities that are both valuable and
> productive to promote in the community there are components of the e-mail
> that may be perceived as less so.  Rather that niggle over the nomenclature
> of the e-mail I might suggest we strip the dialog back to a set of joint
> objectives for the board and technical community to find ways to achieve.
> One way to ask for the steering committee to help steer the community is
> by agreeing on a common set of objectives and allowing the community (whom
> we would want to achieve them) to determine the best way of doing that.
> As I read this list it does not so much present as a set of objectives as
> it does a checklist to report on.  Can these points be re-communicated as a
> set of objectives that the board as stakeholders see’s as valuable for the
> OpenDaylight community to accomplish with some reasoning why?  This could
> be the starting point for a productive and less divisive dialog.
> Maybe the request is to:
> Improve the Stability, Scalability, Security and Performance of the
> project.
> Evaluate if it is possible to Identify a minimum set of baseline project
> components to drive to a mature state
> Find ways of focusing the community on the development and improvement
> of certain use cases per release
> If I read the e-mail below accurately.
> / Chris
> From: Colin Dixon <colin at colindixon.com>
> Date: Thursday 26 March 2015 18:21
> To: "tsc at lists.opendaylight.org" <tsc at lists.opendaylight.org>, "
> board at lists.opendaylight.org" <board at lists.opendaylight.org>
> Subject: [OpenDaylight TSC] board requests of the TSC
> Coming out of a recent meeting, the board has made the following requests
> of the TSC. We'll cover them (or at least start) during today's TSC meeting.
> The members of the TSC who also sit on the board will be there to help
> provide context and we can start thinking about how we can address these
> requests.
> Thanks,
> --Colin
> * The board seeks to improve Stability, Scalability, Security and
> Performance (S3P) of future ODL Simultaneous releases, and requests the TSC
> to create a clear S3P criteria / requirement and metrics to measure S3P in
> each release.  The board further asks the TSC to update the Project Life
> Cycle document to support the S3P concept in future releases and as a
> criteria for upgrading a project to a “Mature” state.
> * The board also requests that the TSC recommends a list of projects that
> constitute the “ODL kernel” (i.e. providing key and essential functionality
> without which, ODL can’t deliver basic functionality, including user
> expected most basic plugins) for future ODL releases. Proposed list for TSC
> consideration includes: Controller (including MD-SAL/Yang), OpenFlow
> plugin, neutron plugin, network virtualization code, AAA, OVSDB and topology
> * The board recommends that ODL focuses on the following Use Cases for
> Lithium and Beryllium releases, (at a minimum): Network Virtualization and
> Service Chaining. To support this Use Case focus, the board also requests
> the TSC to define the list of projects and capabilities needed and build
> tests to validate they adhere to the TSC defined S3P criteria. The board
> further asks the TSC to work with the ODL Advisory Group to gather their
> feedback for these use cases, and report to board periodically on its
> progress on these tasks.
> * The board requests the TSC to prepare a plan for shipping the “ODL
> kernel” and the projects required for the Use Cases (listed below) as
> “Mature” projects with S3P for the Beryllium release as part of the
> simultaneous release and advise he board on best effort plan for partially
> achieving these goals for Lithium. The TSC will provide the board with
> resources requirement estimate for achieving the goal, as well as a list of
> expected gaps and suggestions for addressing them.
> * The board tasks TSC to create a comprehensive test plan to achieve and
> validate S3P including identifying the resource needed for Lithium and
> Beryllium (per “ODL kernel” and targeted Use Cases) and present to the
> Board for discussion in its next meeting and get the board’s support in
> identifying additional resources. These may include platform performance,
> datastore and IO performance, per TSC decisions
> * The board requests the TSC to recommend a plan for converging future ODL
> releases, on a small set (ideally one) of projects/technologies essential
> for the use cases identified for those releases.
> _______________________________________________ TSC mailing list
> TSC at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/tsc
> _______________________________________________
> TSC mailing list
> TSC at lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/tsc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opendaylight.org/pipermail/tsc/attachments/20150331/efb6f2f9/attachment-0001.html>

More information about the TSC mailing list