User Tools

Site Tools


OPNFV OpenDaylight community page

Rather than establish a project for OpenDaylight, the OPNFV community has agreed to work on establishing focus community groups where we will describe community engagement practices, identify community leaders, manage our contributions toward those communities and generally get ourselves organised well enough to be a benefit, rather than a burden, to our source communities.

In general, we would like to have a consistent process for feature requests across OPNFV projects. Since the bar in terms of structure and information seems to be highest for OpenStack, we will align feature request documentation on the OpenStack blueprint process. The process is defined for requirements projects.

In short, projects should create a high-level OPNFV requirements document, an OpenDaylight blueprint, and after an OPNFV review, should transition to upstream projects for community review and discussion.

  1. Projects first create an OPNFV requirement document in Markdown in the project repository: repository/requirements/reference_document.rst - this document should describe the goal at a high level for ONFV consumers
  2. A requirement will result in one or more blueprints for a project which should be drafted (one blueprint per file) in repository/design_docs/reference_document.rst - if features affect multiple projects, there should be a single blueprint per project
  3. These files should be proposed for review in OPNFV's Gerrit, and should follow the OpenStack blueprint template format (example for Ceilometer)
  4. After a successful community sanity check, verifying that the spec has sufficient implementation details and conforms with the minimum expectations of an OpenDaylight feature request, the blueprint should be proposed to the upstream project.

OpenDaylight planning process

OpenDaylight is a collection of loosely affiliated projects, under a common project umbrella. Projects commit to a simultaneous release process with a series of milestones. How the projects organise themselves within that release process is a matter for the project developers.

OpenDaylight projects are organised into three groups:

  • Offset 0: Core projects, required by all others: Controller, yangtools, odlparent
  • Offset 1: Key network services required by other projects: OVSDB, OpenFlow, Neutron NB, topology manager, …
  • Offset 2: No projects depend on these to operate. Some examples relevant to OPNFV are SFC, GBP, VPN Service, …

Projects in Offset 1 typically have deadlines set 1 or 2 weeks after Offset 0 projects, and Offset 2 projects are similarly offset from Offset 1.

Key milestones:

  • M0: Release plan is approved (immediately after previous release)
  • 2-4 weeks after M0: New project proposal deadline. New projects require a 2 week discussion period.
  • M1: New project approval deadline. Projects should have a leader and a draft release plan.
  • M2: 6 weeks after M1. Projects should have finalised release plan and completed the project checklist
  • M3: 4 weeks after M2 (+2 weeks for Offset 1, +4 weeks for Offset 2): Functionality freeze, external APIs published, Karaf features defined
  • M4: 4 weeks after M3: API freeze, documentation, integration test plan deliverables
  • M5: 4 weeks after M4: Code freeze, stable branch creation

Release candidates will be made as necessary, starting 6 weeks after M5 (all projects commit to RC dates).

Projects of particular interest to OPNFV

Table with OPNFV-related projects, links to their feature planning, mailing list and other relevant information.

Project Description Mailing list Lithium release plan
ODL Root
OVSDB integration
OpenFlow OpenFlow Plugin Project lithium plan
Neutron NB
SFC Service Function Chaining lithium plan
GBP Group-based Policy Lithium Plan
AAA Authentication and authorization
SDNi Interconnection of multiple SDN controllers
Reservation Resource reservation
DLUX User interface project
Project Description Relevant ODL projects
Inspector Inspector's goal is to have a full stack security audit framework. Since part of the audit compliance affects the network, audit requirements need to be communicated to ODL, and implemented there
Service Function Chaining We need to define service function chains, and communicate those to the SDN controller, which will implement the chains through flow management. SFC and GPB
Genesis Genesis is about deploying OpenDaylight with OpenStack as a Neutron back-end. ODL as a network virtualization solution is a basic requirement Neutron NBI, OVSDB integration, and OpenFlow primarily
community/opendaylight.txt · Last modified: 2015/06/12 13:49 by Dave Neary