-------- Original Message --------

Subject:	Design topics
Date:	Tue, 16 Sep 2014 01:00:39 +0200
From:	Robert Varga <nite@...>
To:	dev <controller-dev@...>, "discuss@..." <discuss@...>

Hello,

for the design summit, we would like to propose the following topics, in no particular order:

Introduction to OpenDaylight architecture
A general overview of how the infrastructure pieces fit together, what concerns they address. Covers the four major pieces of yangtools (parser, model API, data API, codegen), the three aspects of MD-SAL (notifications, RPCs and the datastore), and how this core is extended with generic applications (like RESTCONF) and non-mandatory infrastructure (like clustering).

MD-SAL Applications 101
A general introduction of how to build an application, general design principles, infrastructure available to get developer jump-started.

Designing applications for efficient datastore interactions
The datastore is probably the key component in application and plugin design. While it can be a very powerful tool, it is does not solve all problems and it is geared towards certain types of interactions. This session aims to provide an overview of the performance characteristics and kinks are, along with in-depth discussion of the tradeoffs involved.

Efficient DataChangeListener API design
The aim is to gather feedback from datastore users as to what information they need, what the context is and how the information is acted up on. The end result should be a comprehensive set of use cases and requirements, which will drive the design of Lithium API design, so that the infrastructure provides more of what applications need.

Java Binding Specification v2
The Java classes we currently generate out of models have several rough edges, which make them less than breezy to use. This topic aims to get the discussion going on how we can address https://bugs.opendaylight.org/show_bug.cgi?id=1411 in a way which is as convenient to the end user as possible.

The path to Java 8
Most recent version of our favorite language brings about a lot of cool language features and significant run-time environment improvements (no PermGen :-)), but unfortunately neither our code, nor our infrastructure is ready to make the transition. This topic revolves around plotting a course of action which would identify and address the blocking issues in Lithium timeframe if possible.

Inter-project infrastructure services
Setting up and maintaining a project is not only about knowing that particular problem domain. Project committers have to battle infrastructure integration, autorelease integration, inter-project dependencies and other sources of permanent headache. odlparent is a nice start, but we need to evolve it quite a bit to provide an ecosystem where project want to live because everything Just Works (tm). Session goals are threefold: a) gather current painpoints b) discuss remedies c) agree on a plan of execution.

Inventories, topologies, models, instances and sharing
General discussion of current state of data models, their maturity and sharing. An immediate tie-in is the inventory/topology schism and we would like to ship Lithium with only topology -- how can we get there? What are the community expectations, how should we model our applications and their interactions and where are we headed? One thing that keeps popping up here is the need for a generic, customizable, inter-technology (OF+BGP, NETCONF+OVSDB, you name it) topology aggragator -- can we maybe jump-start the requirements and get a project off the ground?

Saying goodbye to xtend
This would be a very yangtools-specific discussion about how we can get rid of xtend, without introducing another painful dependency. Code generation really needs a good template language, but what are our options, notably if we factor in performance?

YANG, Java, data and the revision statement
A long-standing issue of data versioning, which we still do not have a good story for. The focus is to build up consensus of what the OpenDaylight upgrade/downgrade story should be. Then we should touch on the question of helping developers in data migration and in-depth design of an automated migration tool -- latest Django has some limited tooling around this -- can we generalize it enough to be useful for our models? I sure hope for Mathieu joins us :)

Lithium release plan - mechanics and deadlines
While the Helium release seems to be on track, it is not without hiccups. We believe a slightly augmented release model would lead to mitigated risks and better code quality. A key component to this would be a "Feature Freeze" milestone, placed (2 weeks?) before the API freeze date. We believe such an arrangement would encourage the projects to get their features in first, then make sure APIs support the features cleanly and then focus on pure code quality in 4-6 weeks of ramp-down. Would this help us to not lower our standards just because 'Code Freeze is nigh'?

Feedback is always welcome.

Thanks,
Robert