Jump to: navigation, search

Group Based Policy (GBP)/Releases/Lithium/Release Plan


The Group Based Policy project proposes the following additions to the Lithium release:

  • Added a Neutron API Provider
  • Added the Exception repository.
  • Added the Operation State repository.
  • More modularized features. There currently are only two features defined for The groupbasedpolicy project: odl-groupbasedpolicy-ofoverlay, and odl-integration-compatible-with-groupbasedpolicy. These two features will be deprecated in favor of a more modular set of features.
  • Support for feature-loadable renderers. This will allow the desired renderer to be loaded and used. Note that the Lithium release only supports a single renderer at a time.
  • Support for OpFlex renderer.
  • Support or Plugin to OpenContrail renderer.
  • Integration with OpenStack Group Based Policy.
  • New version of the policy YANG model (fixes errors in the YANG model).

In addition, the policy model from the Helium release will be deprecated in support of the new one (see above), and the features supported in Helium will also be deprecated in support of a more modular set

Release Deliverables

Name Description
Exception Repository A repository for handling policy exceptions
Operational State Repository A repository for handling operational state
Neutron API provider Support MD-SAL Neutron API
OpFlex Renderer A renderer for OpFlex southbound devices
OpenContrail Renderer A renderer for OpenContrail southbound devices
OpenStack Group Based Policy Integration Support for integration with OpenStack Group Based Policy
Feature loadable renderers Provide the ability to load a renderer using features
SFC Integration Integration with Service Function Chaining project for Proof of Concept (POC)
Updated policy model New version of the policy model, which fixes errors caught by pyang utility
Improved feature modularity New features with improved modularity (e.g. policy or endpoint models, renderer, etc.)

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
Increase Unit Test coverage Mandatory
Create Exception Repository Mandatory
Create Operational State Repository Mandatory
UX/UI Mandatory
Create "How to write a renderer" guide Desirable
Multi-Renderer support Mandatory
Move FD/BD/Subnet selection to EP Mandatory
Allow EPs to join multiple EPGs Mandatory
Discovery (EPs) Desirable
Remove state caching Desirable
Multi-tenant support Mandatory
Common tenant support Desirable
Inheritance testing/demo Desirable
Neutron API mapping Mandatory
Change EPR to accommodate port Mandatory
SFC integration Mandatory
Expand Actions from "ALLOW" specifically NAT + LBAAS Mandatory
Intra-EPG policy Desirable
Add port-range to subject-feature-definition/parameter Desirable
Leverage OVSDB CRUD operations Mandatory
M4 4/16/2015
Name Description
API Freeze
Deliverable 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.

  • Unchanged from Helium:
    • register/unregister endpoint, setting conditions,
    • policy, tenant
  • New Lithium:
    • register L3Prefix Endpoint
    • added fields to existing policy API (backwards compatible).
    • Neutron SB Impl for Neutron NB API project.

PLEASE NOTE: items in italics are tenative

  • base
    • policy (CONF/OPER data)
    • endpoint (OPER data)
    • events/exception/health repository (CONF/OPER data)
  • renderers
    • ofoverlay renderer (CONF/OPER data)
    • opflex renderer (CONF/OPER data)
    • opencontrail renderer (CONF/OPER data)
  • providers
    • neutron API implementation (CONF/OPER data)

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 yang-jmx-generator-plugin M3 No Provide YANG JMX generator
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-inventory M3 No Provide inventory model for Nodes (e.g. vSwitches)
openflowplugin model-flow-service M3 No Provide the service for flow programming (needed?)
openflowplugin model-flow-base M3 No Provide the base model for flow programming (needed?)
openflowplugin flow programming M3 No Provide flow programming for switches
openflowplugin openflowplugin-extension-nicira M3 No Support for Nicira extensions (enumerate)
plugin2oc OpenContrail plugin M3 No OpenContrail plugin that provides OpenContrail API support
sfc sfc-model M3 No Service Function Chaining model
sfc sfc-provider M3 No Service Function Chaining Provider (RPCs)
ovsdb ovsdb M3 No Bridge, port, and tunnel CRUD support

Expected Incompatibilities with Other Projects

This OpenFlow Overlay renderer is considered incompatible with applications that program the flow tables on vSwitches. This includes:

  • VTN
  • OpenDOVE

The OpenFlow Overlay renderer attempts to install flows in the flow tables of vSwitches when policy is resolved in order to create a Network Virtualization solution. The applications listed above also provide this functionality, and therefore are incompatible.

These projects have not held discussions as to how to become compatible because they each provide their own solution to the same problem.

Compatibility with Previous Releases

Removed APIs and/or Functionality

  • No APIs will be removed in this release.

Deprecated APIs and/or Functionality

  • N/A

Changed APIs and/or Functionality

  • Please include list of a APIs and/or functionality that existed the previous release and will be changed.
    • N/A

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:


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