Jump to: navigation, search

Controller Core Functionality Tutorials:Lithium Release Plan

Introduction

The Controller Core Functionality Tutorials project proposes the following additions to the Lithium release:

  • In line tutorials on creating a project
    • Archetype structure
    • YANG
    • XML
    • RPCs
    • etc
  • Other projects maybe included in Lithium:
    • OpenFlowPlugin/Java
    • Inventory etc

Release Deliverables

Name Description
Initial draft of simple toaster Simple Toaster
ASCII Doc investigation Self-documenting tutorials in code
OpenFlowPlugin/Java Further Tutorials

Release Milestones

  • Offset: 2
Milestone Offset 2 Date Deliverables
M1 12/25/2014
Name Description
Release Plan Candidate Release Plan
Deliverable Name Deliverable Description
M2 2/5/2015
Name Description
Release Plan Final Release Plan
Deliverable Name Deliverable Description
M3 3/19/2015
Name Description
Feature Freeze
Deliverable Name Deliverable Description
M4 4/16/2015
Name Description
API Freeze
RDeliverable Name Deliverable Description
M5 5/14/2015
Name Description
Code Freeze
Deliverable Name Deliverable Description
RC0 5/28/2014
Name Description
Deliverable Name Deliverable Description
RC1 6/4/2015
Name Description
Deliverable Name Deliverable Description
RC2 6/11/2015
Name Description
Release Review Release Review Description
Deliverable Name Deliverable Description
RC3 6/18/2015
Name Description
Release Review Release Review Description
Deliverable Name Deliverable Description
Formal Release 6/25/2015
Name Description
Deliverable Name Deliverable Description

Externally Consumable APIs

  • Please list and describe all externally consumable APIs or point to a document that does so.
  • This need not be a list of all java interfaces and yang files, but should be a list of high-level functionality, e.g., flow programming.
    • For each such API, there should be a list of the bundles providing the API, but not necessarily the implementation.
  • Each PROVISIONAL or TENTATIVE API must be listed as project deliverable
    • Must be declared as "IN" or "OUT" at the M3 Milestone

Expected Dependencies on Other Projects

Providing Project Deliverable Name Needed By Acknowledged? Description
yangtools yang-binding M3 No Provide binding definitions for YANG
yangtools yang-common M3 No Provide common YANG constructs
yangtools yang-maven-plugin M3 No Provide maven plugin for building YANG models
yangtools maven-sal-api-gen-plugin M3 No Provide maven plugin for SAL API generation
controller config-api M3 No  ??
controller sal-binding-api M3 No Provide Data Broker binding API support
controller sal-binding-config M3 No Provide ???
controller sal-common-util M3 No Provide ???
controller.model model-inventory M3 No Provide inventory model for Nodes (e.g. vSwitches)
controller model-flow-service M3 No Provide the service for flow programming (needed?)
controller model-flow-base M3 No Provide the base model for flow programming (needed?)
controller yang-jmx-generator-plugin M3 No Provide YANG JMX generator

Expected Incompatibilities with Other Projects

  • None

Compatibility with Previous Releases

  • N/A

Removed APIs and/or Functionality

  • N/A

Deprecated APIs and/or Functionality

Changed APIs and/or Functionality

  • Please include list of a APIs and/or functionality that existed the previous release and will be changed.
    • For each such API/functionality, provide guidance about who will be affected and how they should adapt.
    • In general, project's should strive to be backward compatible with the previous release and note what functionality will be removed by deprecating it and noting that with the @Deprecated annotations wherever possible.

Themes and Priorities

Requests from Other Projects

For each API request, the requesting project should create an entry like the example below. After creating the entry, the requesting project should send an e-mail to release@lists.opendaylight.org, and both projects' dev lists using this template:

Subject: [REQUEST FOR NEW OR EXTENDED API] ${API name}

Note: This email is a request from ${requesting project} for a new or
extended API in ${providing project}.

API Name: ${API name}
Request: ${link to the request in the providing project's release plan}

Please let us know if you will be able to provide this new
functionality by the listed milestone. If you need clarifications or
help in providing the API, let us know so we can reach an agreement.

If you feel that providing this API is a bad idea regardless of where
the resources are coming from, please let us know why and ideally,
suggest and alternative.

Example Request

  • Requesting Project:
  • Providing Project: <should be this project, i.e., the project whose release plan this page is>
  • Requested Deliverable Name:
  • Needed Milestone: <e.g., M3, assumed to be at that milestone at the offset of the providing project unless otherwise stated>
  • Requested Deliverable Description: <description of the change or new API needed>
  • Response: <one of Yes, No, Tentative>
    • Description: <provides details of the response, e.g., "Yes, we can do that", "No, that's a bad idea", "No, we don't have the staff", "Tentaive, it's a good idea, but we don't know if we can">
    • Resources From: <should be either the providing project if they agree to do the work or the requesting project if the agree>
    • Link to Section in Requesting Project Release Plan: <if No or Tentative, link to the adjustments in the requesting project's release plan>
    • Link to Section in Providing Project Release Plan: <if Yes or Tentative, link to the deliverable in this release plan>
  • Negotiation:
    • <this should be a back and fort until a response of Yes, No, or Tentative is reached>
    • <it should probably start with a response from the providing project that can be one of Yes, No, or Tentative, OR asking for clarification>
    • <after that it should go back and forth reaching a conclusion and then documented in the Response and Description above>
    • <if the negotiation fails or stalls, the TSC will do it's best to help>

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...)

Other