Jump to: navigation, search

OpenDaylight DLUX:Beryllium:Release Plan


Release Deliverables

Name Description
AAA Integration Use AAA API instead of the HTTP Basic Authentication
Improve development workflow It's not easy to test a DLUX module in karaf. You always need to create the bundle and deploy it.

Add a drag and drop system would help to make the workflow more user friendly

Theming Provide a way to change the theme of DLUX
Revisit DLUX Architecture (Proposal) Some Comments say that DLUX feel heavier than before. DLUX haven't changed that much since Helium, only few modules have been added to it.

An assumption would be that there are more files to fetch and load and it slow down DLUX performance.

Module registration (Proposal) Add a "view system". Each module will register to a view and depending on the actual view displayed by DLUX, modules can be visible or not.
Internal Documentation (Proposal) Add a documentation module like "index.html#/apidoc". This url can show modules who are currently loaded by DLUX and explain their public api.

(Services, Provider, Factories, external library version, link to external library, etc)

Cleaning up Cleaning up DLUX core of unnecessary assets and moving them to appropriate applications.

Release Milestones

Milestone Offset 1 Date Deliverables
M1 07/30/2015
Name Status Description
Release Plan In progress Candidate Release Plan
M2 08/27/2015
Name Status Description
Release Plan Final Release Plan
M3 10/01/2015
Name Status Description
Revisit DLUX Architecture Done - Simplify how controller are loader (no patch for now)

- Local translations file ( patch )

- Change how modules are loaded from the core ( patch )

Feature Freeze
M4 10/29/2015
Name Status Description
API Freeze
Improve development workflow
Module registration
M5 12/03/2015
Name Status Description
Code Freeze
Documentation Update wiki documentation to reflect changes/new features.
RC0 01/07/2016
Name Status Description
Deliverable Name Deliverable Description
RC1 01/14/2016
Name Status Description
Deliverable Name Deliverable Description
RC2 01/21/2016
Name Description
Release Review Release Review Description
Deliverable Name Deliverable Description
RC3 01/28/2016
Name Description
Release Review Release Review Description
Deliverable Name Deliverable Description
Formal Release 02/04/2016
Name Status Description
Deliverable Name Deliverable Description

Externally Consumable APIs

Short Name Description Type (at M2) Type (at M3) Type (release) Contract Supporting Code
API Name Short Description One of Provisional, Tentative, Stable, or Dropped as defined in the Beryrllium release plan definitions. link to the Java interface, YANG file, WSDL description, etc. that defines the API list of Karaf features, OSGi bundles, directories, etc. that provide the API

Expected Dependencies on Other Projects

Deliverable Name | Milestone Needed By | Yes/No/Tentative
(as link to Other Project Release Plan) | Description of the new deliverable or changes to a deliverable

Expected Incompatibilities with Other Projects

Compatibility with Previous Releases

Removed APIs and/or Functionality

Deprecated APIs and/or Functionality

Changed APIs and/or Functionality

Themes and Priorities

Requests from Other Projects

For each API / feature request, the requesting project MUST:

  • open Enhancement bug in Bugzilla describing request with Issue Type: Improvement, Change Request or New Feature
  • create an entry as described in Release Plan - Request template, which will also contain number / link to the bug. After creating the entry, the requesting project MUST:
  • send an e-mail to release@lists.opendaylight.org (mandated by Simultaneous Release)
  • and both projects' dev lists using this template (mandated by Simultaneous Release)
Requesting Project API Name Needed By Acknowledged? Description
XYZ Project call_me M4 No This is an example to request API supported

Test Tools Requirements

  • Please specify if the project will run System Test (ST) inside OpenDaylight cloud
  • In case affirmative please enumerate any test tool (mininet, etc...) you think will be required for testing your project
    • The goal is to start test tools installation in rackspace as soon as possible
  • In case negative be aware you will be required to provide System Test (ST) reports upon any release creation (weekly Release, Release Candidate, Formal Release, etc...)