Page tree
Skip to end of metadata
Go to start of metadata

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

 

 

 

Controller

 

 

 

OVSDB integration

 

 

 

OpenFlow

OpenFlow Plugin Project

<openflowplugin-dev@lists.opendaylight.org>

lithium plan

Neutron NB

 

 

 

SFC

Service Function Chaining

<sfc-dev@lists.opendaylight.org>

lithium plan

GBP

Group-based Policy

<groupbasedpolicy-dev@lists.opendaylight.org>

Lithium Plan

AAA

Authentication and authorization

 

 

SDNi

Interconnection of multiple SDN controllers

 

 

Reservation

Resource reservation

 

 

DLUX

User interface project

 

 

OpenDaylight related OPNFV projects/features

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 Home

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

  • No labels