-[submodule "docs/submodules/bgpcep"]
- path = docs/submodules/bgpcep
- url = ../bgpcep
- branch = .
- ignore = dirty
[submodule "docs/submodules/infrautils"]
path = docs/submodules/infrautils
url = ../infrautils
branch = .
ignore = dirty
-[submodule "docs/submodules/aaa"]
- path = docs/submodules/aaa
- url = ../aaa
- branch = .
- ignore = dirty
-[submodule "docs/submodules/netconf"]
- path = docs/submodules/netconf
- url = ../netconf
- branch = .
- ignore = dirty
-[submodule "docs/submodules/odlparent"]
- path = docs/submodules/odlparent
- url = ../odlparent
- branch = .
- ignore = dirty
-[submodule "docs/submodules/genius"]
- path = docs/submodules/genius
- url = ../genius
- branch = .
- ignore = dirty
-[submodule "docs/submodules/ovsdb"]
- path = docs/submodules/ovsdb
- url = ../ovsdb
- branch = .
- ignore = dirty
-[submodule "docs/submodules/federation"]
- path = docs/submodules/federation
- url = ../federation
- branch = master
-[submodule "docs/submodules/coe"]
- path = docs/submodules/coe
- url = ../coe
- branch = .
- ignore = dirty
[submodule "docs/submodules/sfc"]
path = docs/submodules/sfc
url = ../sfc
url = ../openflowplugin
branch = .
ignore = dirty
-[submodule "docs/submodules/yangtools"]
- path = docs/submodules/yangtools
- url = ../yangtools
-[submodule "docs/submodules/mdsal"]
- path = docs/submodules/mdsal
- url = ../mdsal
--- /dev/null
+formats:
+ - htmlzip
+
+requirements_file: requirements.txt
+
+build:
+ image: latest
+
# Append to intersphinx_mapping
intersphinx_mapping['odl-integration-test'] = ('http://docs.opendaylight.org/projects/integration-test/en/latest/', None)
+intersphinx_mapping['odl-integration-distribution'] = ('http://docs.opendaylight.org/projects/integration-distribution/en/latest/', None)
intersphinx_mapping['odl-integration-packaging'] = ('http://docs.opendaylight.org/projects/integration-packaging/en/latest/', None)
intersphinx_mapping['odl-releng-builder'] = ('http://docs.opendaylight.org/projects/releng-builder/en/latest/', None)
# Projects that have stable/branches
+intersphinx_mapping['coe'] = ('http://docs.opendaylight.org/projects/coe/en/latest/', None)
+intersphinx_mapping['genius'] = ('http://docs.opendaylight.org/projects/genius/en/latest/', None)
intersphinx_mapping['netvirt'] = ('http://docs.opendaylight.org/projects/netvirt/en/latest/', None)
+# OpenDaylight Documentation Releases
+intersphinx_mapping['odl-oxygen'] = ('http://docs.opendaylight.org/en/stable-oxygen/', None)
+intersphinx_mapping['odl-nitrogen'] = ('http://docs.opendaylight.org/en/stable-nitrogen/', None)
+intersphinx_mapping['odl-carbon'] = ('http://docs.opendaylight.org/en/stable-carbon/', None)
+
linkcheck_ignore = [
# Ignore jenkins because it's often slow to respond.
'https://jenkins.opendaylight.org/releng',
'https://jenkins.opendaylight.org/sandbox',
- 'http://\$CONTROL_HOST:8181/dlux/index.html',
# The '#' in the path makes sphinx think it's an anchor
'https://git.opendaylight.org/gerrit/#/admin/projects/releng/builder',
]
nitpicky = True
release = version
-
template of the service RPC. You can define your own RPC using
``augment`` in YANG. Here is an example in ``alto-simpleird``.
-.. code:: yang
+.. code::
grouping "alto-ird-request" {
container "ird-request" {
Authorization <http://shiro.apache.org/web.html#Web-%7B%7B%5Curls%5C%7D%7D>`_
describes how to configure the Authentication feature in detail.
-.. notes::
+.. note::
The Shiro-Based Authorization that uses the *shiro.ini* URLs section to
define roles requirements is **deprecated** and **discouraged** since the
.. _bgp-developer-guide:
+
BGP Developer Guide
===================
Javadocs are generated while creating mvn:site and they are located in
target/ directory in each module.
-
.. _bgp-monitoring-protocol-developer-guide:
+
BGP Monitoring Protocol Developer Guide
=======================================
Javadocs are generated while creating mvn:site and they are located in
target/ directory in each module.
-
Declaring a routing context type
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-.. code:: yang
+.. code::
identity node-context {
description "Identity used to mark node context";
RPCs, we need to model that set accordingly using ``context-instance``
extension from the ``yang-ext`` model.
-.. code:: yang
+.. code::
import yang-ext { prefix ext; }
This is achieved using YANG extension ``context-reference`` from
``yang-ext`` model on leaf, which will be used for RPC routing.
-.. code:: yang
+.. code::
rpc example-routed-rpc {
input {
----------------------------------------
RESTCONF operations overview
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| RESTCONF allows access to datastores in the controller.
| There are two datastores:
creation of a default instance, it acts as a regular instance and fully
participates in the configuration subsystem (It can be reconfigured or
deleted in following transactions.).
-
- A development environment with following set up and working correctly
from the shell:
- - Maven 3.1.1 or later
+ - Maven 3.5.2 or later
- - Java 7- or Java 8-compliant JDK
+ - Java 8-compliant JDK
- An appropriate Maven settings.xml file. A simple way to get the
default OpenDaylight settings.xml file is:
.. code:: shell
- mvn archetype:generate -DarchetypeGroupId=org.opendaylight.controller -DarchetypeArtifactId=opendaylight-startup-archetype \
- -DarchetypeRepository=https://nexus.opendaylight.org/content/repositories/<opendaylight.release | opendaylight.snapshot>/ \
- -DarchetypeCatalog=remote -DarchetypeVersion=<Archetype-Version>
+ mvn archetype:generate -DarchetypeGroupId=org.opendaylight.archetypes -DarchetypeArtifactId=opendaylight-startup-archetype \
+ -DarchetypeCatalog=remote -DarchetypeVersion=1.0.0-SNAPSHOT
- To find the correct <Archetype-Version> for an OpenDaylight release, search https://nexus.opendaylight.org for the
- ``archetypeArtifactId`` (e.g. ``https://nexus.opendaylight.org/#nexus-search;quick~opendaylight-startup-archetype``); and if it's a
- ``*-SNAPSHOT`` then use ``-DarchetypeRepository=https://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/``, otherwise
- use ``-DarchetypeRepository=https://nexus.opendaylight.org/content/repositories/opendaylight.release/``.
+ To find the correct <Archetype-Version> for an OpenDaylight release, search https://nexus.opendaylight.org;
+ e.g. ``https://nexus.opendaylight.org/#nexus-search;gav~org.opendaylight.archetypes~~~~``.
-2. Update the properties values as follows. Ensure that the groupid and
- the artifactid is lower case.
+2. Update the properties values as follows. Ensure that the values for the groupId and
+ the artifactId are in lower case.
.. code:: shell
log:display | grep Example
-8. Shutdown the OpenDaylight through the console by using the following
+8. Shutdown OpenDaylight through the console by using the following
command.
.. code:: shell
Defining a Simple Hello World RPC
---------------------------------
-1. | Run the maven archetype *opendaylight-startup-archetype*, and
- create the *hello* project.
+1. | Build a *hello* example from the Maven archetype *opendaylight-startup-archetype*,
+ same as above.
- .. code:: shell
-
- mvn archetype:generate -DarchetypeGroupId=org.opendaylight.controller -DarchetypeArtifactId=opendaylight-startup-archetype \
- -DarchetypeRepository=http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/ \
- -DarchetypeCatalog=http://nexus.opendaylight.org/content/repositories/opendaylight.snapshot/archetype-catalog.xml
-
-2. Update the Properties values as follows.
-
- .. code:: shell
-
- Define value for property 'groupId': : org.opendaylight.hello
- Define value for property 'artifactId': : hello
- Define value for property 'version': 1.0-SNAPSHOT: : 1.0.0-SNAPSHOT
- Define value for property 'package': org.opendaylight.hello: :
- Define value for property 'classPrefix': ${artifactId.substring(0,1).toUpperCase()}${artifactId.substring(1)}
- Define value for property 'copyright': : Copyright(c) Yoyodyne, Inc.
-
-3. View the *hello* project.
-
- .. code:: shell
-
- cd hello/
- ls -1
- api
- artifacts
- features
- impl
- karaf
- pom.xml
-
-4. Build *hello* project by using the following command.
-
- .. code:: shell
-
- mvn clean install
-
-5. Verify that the project is functioning by executing karaf.
-
- .. code:: shell
-
- cd karaf/target/assembly/bin
- ./karaf
-
-6. | The karaf cli appears as follows.
- | NOTE: Remember to wait for OpenDaylight to load completely. Verify
- that the Java process CPU has stabilized.+
-
- .. code:: shell
-
- opendaylight-user@root>
-
-7. Verify that the *hello* module is loaded by checking the log.
-
- .. code:: shell
-
- log:display | grep Hello
-
-8. Shutdown karaf.
-
- .. code:: shell
-
- shutdown -f
-
-9. Return to the top of the directory structure:
-
- .. code:: shell
-
- cd ../../../../
-
-10. View the entry point to understand where the log line came from. The
+2. Now view the entry point to understand where the log line came from. The
entry point is in the impl project:
.. code:: shell
impl/src/main/java/org/opendaylight/hello/impl/HelloProvider.java
-11. Add any new things that you are doing in your implementation by
- using the HelloProvider.onSessionInitiate method. Its analogous to
+3. Add any new things that you are doing in your implementation by
+ using the HelloProvider.onSessionInitiate method. It's analogous to
an Activator.
.. code:: java
2. Edit this file as follows. In the following example, we are adding
the code in a YANG module to define the *hello-world* RPC:
- .. code:: yang
+ .. code::
module hello {
yang-version 1;
.. code:: java
package org.opendaylight.hello.impl;
+
import java.util.concurrent.Future;
import org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.hello.rev150105.HelloService;
import org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.hello.rev150105.HelloWorldInput;
import org.opendaylight.yang.gen.v1.urn.opendaylight.params.xml.ns.yang.hello.rev150105.HelloWorldOutputBuilder;
import org.opendaylight.yangtools.yang.common.RpcResult;
import org.opendaylight.yangtools.yang.common.RpcResultBuilder;
+
public class HelloWorldImpl implements HelloService {
+
@Override
public Future<RpcResult<HelloWorldOutput>> helloWorld(HelloWorldInput input) {
HelloWorldOutputBuilder helloBuilder = new HelloWorldOutputBuilder();
import org.slf4j.LoggerFactory;
public class HelloProvider implements BindingAwareProvider, AutoCloseable {
+
private static final Logger LOG = LoggerFactory.getLogger(HelloProvider.class);
private RpcRegistration<HelloService> helloService;
+
@Override
public void onSessionInitiated(ProviderContext session) {
LOG.info("HelloProvider Session Initiated");
helloService = session.addRpcImplementation(HelloService.class, new HelloWorldImpl());
}
+
@Override
public void close() throws Exception {
LOG.info("HelloProvider Closed");
make sure the helloService member is being set. By not invoking
"session.addRpcImplementation()" the REST API will be unable to map
/operations/hello:hello-world url to HelloWorldImpl.
-
.. _didm-developer-guide:
+
DIDM Developer Guide
====================
http://${controller-ip}:8181/apidoc/explorer/index.html,
and look under DIDM section to see all the available REST calls and
tables
-
+++ /dev/null
-DLUX
-====
-
-Setup and Run
--------------
-
-Required Technology Stack
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- AngularJS (JavaScript client-side framework, http://www.angularjs.org
- )
-
-Run DLUX
-~~~~~~~~
-
-To turn on the DLUX UI, install DLUX core feature via running following
-command on the Karaf console -
-
-::
-
- feature:install odl-dlux-core
-
-The above command will install odl-restconf along with core DLUX components. Once this
-feature is successfully installed, access the UI at
-http://localhost:8181/index.html. The default credentials for login are
-admin/admin. After successful login you'll see empty page.
-For applications, continue with DluxApps project.
-
-DLUX Modules
-------------
-
-DLUX modules are the individual features such as nodes and topology.
-Each module has a defined structure and you can find all existing
-modules at
-https://github.com/opendaylight/dlux/tree/stable/boron/modules.
-
-Module Structure
-~~~~~~~~~~~~~~~~
-
-- module\_folder
-
- - <module\_name>.module.js
-
- - <module\_name>.controller.js
-
- - <module\_name>.services.js
-
- - <module\_name>.directives.js
-
- - <module\_name>.filter.js
-
- - index.tpl.html
-
- - <a\_stylesheet>.css
-
-Create New Module
-~~~~~~~~~~~~~~~~~
-
-Define the module
-^^^^^^^^^^^^^^^^^
-
-1. Create an empty maven project and create your module folder under
- src/main/resources.
-
-2. Create an empty file with pattern <module\_name>.module.js.
-
-3. Next, you need to surround the angular module with a define function.
- This allows RequireJs to see our module.js files. The first argument
- is an array which contains all the module’s dependencies. The second
- argument is a callback function, whose body contain the AngularJS
- code base. The function parameters correspond with the order of
- dependencies. Each dependency is injected into a parameter, if it is
- provided.
-
-4. Finally, you will return the angular module to be able to inject it
- as a parameter in others modules.
-
-For each new module, you must have at least these two dependencies :
-
-- angularAMD : It’s a wrapper around AngularJS to provide an AMD
- (Asynchronous Module Definition) support, which is used by RequireJs.
- For more information see the `AMD
- documentation <https://github.com/amdjs/amdjs-api/blob/master/AMD.md>`__.
-
-- app/core/core.services : This one is mandatory, if you want to add
- content in the navigation menu, the left bar or the top bar.
-
-The following are not mandatory, but very often used.
-
-- angular-ui-router : A library to provide URL routing.
-
-- routingConfig : To set the level access to a page.
-
-Your module.js file might look like this:
-
-::
-
- define(['angularAMD','app/routingConfig', 'angular-ui-router','app/core/core.services'], function(ng) {
- var module = angular.module('app.a_module', ['ui.router.state', 'app.core']);
- // module configuration
- module.config(function() {
- [...]
- });
- return module;
- });
-
-Set the register function
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-AngularJS allows lazy registration of a module’s components such as
-controller, factory etc. Once you will install your application, DLUX
-will load your module javascript, but not your angular component during
-bootstrap phase. You have to register your angular components to make
-sure they are available at the runtime.
-
-Here is how to register your module’s component for lazy initialization
--
-
-::
-
- module.config(function($compileProvider, $controllerProvider, $provide) {
- module.register = {
- controller : $controllerProvider.register,
- directive : $compileProvider.directive,
- factory : $provide.factory,
- service : $provide.service
- };
- });
-
-Set the route
-^^^^^^^^^^^^^
-
-The next step is to set up the route for your module. This part is also
-done in the configuration method of the module. We have to add
-**$stateProvider** as a parameter.
-
-::
-
- module.config(function($stateProvider) {
- var access = routingConfig.accessLevels;
- $stateProvider.state('main.module', {
- url: 'module',
- views : {
- 'content' : {
- templateUrl: 'src/app/module/module.tpl.html',
- controller: 'ModuleCtrl'
- }
- }
- });
- });
-
-Adding element to the navigation menu
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To be able to add item to the navigation menu, the module requires the
-**NavHelperProvider** parameter in the configuration method.
-**addToMenu** method in **NavMenuHelper** helper allows an item addition
-to the menu.
-
-::
-
- var module = angular.module('app.a_module', ['app.core']);
- module.config(function(NavMenuHelper) {
- NavMenuHelper.addToMenu('myFirstModule', {
- "link" : "#/module/index",
- "active" : "module",
- "title" : "My First Module",
- "icon" : "icon-sitemap",
- "page" : {
- "title" : "My First Module",
- "description" : "My first module"
- }
- });
- });
-
-The first parameter is an ID that refers to the level of your menu and
-the second is a object. For now, The ID parameter supports two levels of
-depth. If your ID looks like *rootNode.childNode*, the helper will look
-for a node named *rootNode* and it will append the *childNode* to it. If
-the root node doesn’t exist, it will create it.
-
-Link the AngularJS module’s controller file
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To include the module’s controller file, you can use the
-NavHelperProvider. It contains a method that will load the given file.
-
-::
-
- [...]
- NavHelperProvider.addControllerUrl('<path_to_module_folder>/<module_name>.controller');
-
-This completes your module.js file.
-
-Create the controller, factory, directive, etc
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Creating the controller and other components is similar to the module.
-
-- First, add the define method.
-
-- Second, add the relative path to the module definition.
-
-- Last, create your methods as you usually do it with AngularJS.
-
-For example -
-
-::
-
- define(['<relative_path_to_module>/<module_name>.module'], function(module) {
- module.register.controller('ModuleCtrl', function($rootScope, $scope) {
- });
- });
-
-Add new application using DLUX modularity
------------------------------------------
-
-DLUX works as a Karaf based UI platform, where you can create a new
-Karaf feature of your UI component and install that UI applications in
-DLUX using blueprint. This page will help you to create and load a new
-application for DLUX. You don’t have to add new module in DLUX
-repository.
-
-Add a new OSGi blueprint bundle
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The OSGi Blueprint Container specification allows us to use dependency
-injection in our OSGi environment. Each DLUX application module
-registers itself via blueprint configuration. Each application will have
-its own blueprint.xml to place its configuration.
-
-1. Create a maven project to place blueprint configuration. For
- reference, take a look at topology bundle, present at
- https://github.com/opendaylight/dlux/tree/stable/boron/bundles/topology.
- All the existing DLUX modules' configurations are available under
- bundles directory of DLUX code.
-
-2. In pom.xml, you have to add a maven plugin to unpack your module code
- under generated-resources of this project. For reference, you can
- check pom.xml of dlux/bundles/topology at
- https://github.com/opendaylight/dlux/tree/stable/boron/bundles/topology.
- Your bundle will eventually get deployed in Karaf as feature, so your
- bundle should contain all your module code. If you want to combine
- module and bundle project, that should not be an issue either.
-
-3. Create a blueprint.xml configuration file under
- src/main/resources/OSGI-INF/blueprint. Below is the content of the
- blueprint.xml taken from topology bundles’s blueprint.xml. Any new
- application should create a blueprint.xml in following format -
-
-::
-
- <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
- <reference id="httpService" availability="mandatory" activation="eager" interface="org.osgi.service.http.HttpService"/>
- <reference id="loader" availability="mandatory" activation="eager" interface="org.opendaylight.dlux.loader.DluxModuleLoader"/>
-
- <bean id="bundle" init-method="initialize" destroy-method="clean" class="org.opendaylight.dlux.loader.DluxModule">
- <property name="httpService" ref="httpService"/>
- <property name="loader" ref="loader"/>
- <property name="moduleName" value="topology "/>
- <property name="url" value="/src/app/topology"/>
- <property name="directory" value="/topology"/>
- <property name="requireJs" value="app/topology/topology.module"/>
- <property name="angularJs" value="app.topology"/>
- <property name="cssDependencies">
- <list>
- <value>http://yui.yahooapis.com/3.18.1/build/cssreset/cssreset-min.css</value>
- <value>src/app/topology/topology-custom.css</value>
- </list>
- </property>
- </bean>
- </blueprint>
-
-In above configuration, there are two references with id httpService and
-loader. These two beans will already be initialized by dlux-core, so any
-new application can use them. Without these two bean references, a new
-application will not be able to register.
-
-Next is the initialization of your application bean, which will be an
-instance of class org.opendaylight.dlux.loader.DluxModule. There are 5
-properties that you should provide in this bean besides the references
-of httpService and loader. Lets talk about those bean properties in
-little more detail.
-
-**moduleName** : Name of your module. This name should be unique in
-DLUX.
-
-**url**: This is the url via which RequireJS in DLUX will try to load
-your module JS/HTML files. Also, this is the url that browser will use
-to load the static HTML, JS or CSS files. RequireJS in DLUX has a base
-path of **src**, so all the url should start with /src so RequireJS and
-the browser can correctly find the files.
-
-**directory**: In your bundle’s pom.xml, you unpack your module code.
-This is the directory where your actual static files will reside. The
-above mentioned url is registered with httpService, so when browser
-makes a call to that url, it will be redirected to the directory
-mentioned here. In the above example, all the topology files are present
-under /topology directory and the browser/RequireJS can access those
-files with uri /src/app/topology.
-
-**requireJS**: This is the path to your RequireJS module. If you notice
-closely, you will see the initial path of RequireJS app/topology in the
-above example matches with the last part of url. This path will be be
-used by RequireJS. As mentioned above, we have kept **src** as base path
-in RequireJS, that is the exact reason that url start with /src.
-
-**angularJS**: name of your AngularJS module.
-
-**cssDependencies**: If the application has any external/internal css
-dependencies, then those can be added here. If you create your own css
-files, just point to those css files here. Use the url path that you
-mentioned above, so the browser can find your css file.
-
-OSGi understands blueprint.xml, once you will deploy your bundle in
-karaf (or you can create a new feature for your application), karaf will
-read your blueprint.xml and it will try to register your application
-with dlux. Once successful, if you refresh your dlux UI, you will see
-your application in left hand navigation bar of dlux.
-
-Yang Utils
-----------
-
-Yang Utils are used by UI to perform all CRUD operations. All of these
-utilities are present in yangutils.services.js file. It has following
-AngularJS factories -
-
-- **arrayUtils** – defines functions for working with arrays.
-
-- **pathUtils** – defines functions for working with xpath (paths to
- APIs and subAPIs). It divides xpath string to array of elements, so
- this array can be later used for search functions.
-
-- **syncFact** – provides synchronization between requests to and from
- OpenDaylight when it’s needed.
-
-- **custFunct** – it is linked with
- apiConnector.createCustomFunctionalityApis in yangui controller in
- yangui.controller.js. That function makes it possible to create some
- custom function called by the click on button in index.tpl.html. All
- custom functions are stored in array and linked to specific subAPI.
- When particular subAPI is expanded and clicked, its inputs (linked
- root node with its child nodes) are displayed in the bottom part of
- the page and its buttons with custom functionality are displayed
- also.
-
-- **reqBuilder** – Builds object in JSON format from input fields of
- the UI page. **Show Preview** button on Yang UI use this builder.
- This request is sent to OpenDaylight when button PUT or POST is
- clicked.
-
-- **yinParser** – factory for reading .xml files of yang models and
- creating object hierarchy. Every statement from yang is represented
- by a node.
-
-- **nodeWrapper** – adds functions to objects in tree hierarchy created
- with yinParser. These functions provide functionality for every type
- of node.
-
-- **apiConnector** – the main functionality is filling the main
- structures and linking them. Structure of APIs and subAPIs which is
- two level array - first level is filled by main APIs, second level is
- filled by others sub APIs. Second main structure is array of root
- nodes, which are objects including root node and its children nodes.
- Linking these two structures is creating links between every subAPI
- (second level of APIs array) and its root node, which must be
- displayed like inputs when subAPI is expanded.
-
-- **yangUtils** – some top level functions which are used by yangui
- controller for creating the main structures.
-
+++ /dev/null
-=================
-DLUX Applications
-=================
-
-Setup and Run
--------------
-
-Required Technology Stack
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- AngularJS (JavaScript client-side framework, http://www.angularjs.org
- )
-
-Run DLUX
-~~~~~~~~
-
-To turn on the DLUX Applications, install feature via running following
-command on the Karaf console -
-
-::
-
- feature:install odl-dluxapps-applications
-
-The above command will install odl-dlux-core along with all DLUX applications. Once this
-feature is successfully installed, access the UI at
-http://localhost:8181/index.html. The default credentials for login are
-admin/admin.
-
-DLUX Modules
-------------
-
-DLUX modules are the individual features such as nodes and topology.
-Each module has a defined structure and you can find all existing
-modules at
-https://github.com/opendaylight/dlux/tree/stable/boron/modules.
-
-Module Structure
-~~~~~~~~~~~~~~~~
-
-- module\_folder
-
- - <module\_name>.module.js
-
- - <module\_name>.controller.js
-
- - <module\_name>.services.js
-
- - <module\_name>.directives.js
-
- - <module\_name>.filter.js
-
- - index.tpl.html
-
- - <a\_stylesheet>.css
-
-Create New Module
-~~~~~~~~~~~~~~~~~
-
-Define the module
-^^^^^^^^^^^^^^^^^
-
-1. Create an empty maven project and create your module folder under
- src/main/resources.
-
-2. Create an empty file with pattern <module\_name>.module.js.
-
-3. Next, you need to surround the angular module with a define function.
- This allows RequireJs to see our module.js files. The first argument
- is an array which contains all the module’s dependencies. The second
- argument is a callback function, whose body contain the AngularJS
- code base. The function parameters correspond with the order of
- dependencies. Each dependency is injected into a parameter, if it is
- provided.
-
-4. Finally, you will return the angular module to be able to inject it
- as a parameter in others modules.
-
-For each new module, you must have at least these two dependencies :
-
-- angularAMD : It’s a wrapper around AngularJS to provide an AMD
- (Asynchronous Module Definition) support, which is used by RequireJs.
- For more information see the `AMD
- documentation <https://github.com/amdjs/amdjs-api/blob/master/AMD.md>`__.
-
-- app/core/core.services : This one is mandatory, if you want to add
- content in the navigation menu, the left bar or the top bar.
-
-The following are not mandatory, but very often used.
-
-- angular-ui-router : A library to provide URL routing.
-
-- routingConfig : To set the level access to a page.
-
-Your module.js file might look like this:
-
-::
-
- define(['angularAMD','app/routingConfig', 'angular-ui-router','app/core/core.services'], function(ng) {
- var module = angular.module('app.a_module', ['ui.router.state', 'app.core']);
- // module configuration
- module.config(function() {
- [...]
- });
- return module;
- });
-
-Set the register function
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-AngularJS allows lazy registration of a module’s components such as
-controller, factory etc. Once you will install your application, DLUX
-will load your module javascript, but not your angular component during
-bootstrap phase. You have to register your angular components to make
-sure they are available at the runtime.
-
-Here is how to register your module’s component for lazy initialization
--
-
-::
-
- module.config(function($compileProvider, $controllerProvider, $provide) {
- module.register = {
- controller : $controllerProvider.register,
- directive : $compileProvider.directive,
- factory : $provide.factory,
- service : $provide.service
- };
- });
-
-Set the route
-^^^^^^^^^^^^^
-
-The next step is to set up the route for your module. This part is also
-done in the configuration method of the module. We have to add
-**$stateProvider** as a parameter.
-
-::
-
- module.config(function($stateProvider) {
- var access = routingConfig.accessLevels;
- $stateProvider.state('main.module', {
- url: 'module',
- views : {
- 'content' : {
- templateUrl: 'src/app/module/module.tpl.html',
- controller: 'ModuleCtrl'
- }
- }
- });
- });
-
-Adding element to the navigation menu
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To be able to add item to the navigation menu, the module requires the
-**NavHelperProvider** parameter in the configuration method.
-**addToMenu** method in **NavMenuHelper** helper allows an item addition
-to the menu.
-
-::
-
- var module = angular.module('app.a_module', ['app.core']);
- module.config(function(NavMenuHelper) {
- NavMenuHelper.addToMenu('myFirstModule', {
- "link" : "#/module/index",
- "active" : "module",
- "title" : "My First Module",
- "icon" : "icon-sitemap",
- "page" : {
- "title" : "My First Module",
- "description" : "My first module"
- }
- });
- });
-
-The first parameter is an ID that refers to the level of your menu and
-the second is a object. For now, The ID parameter supports two levels of
-depth. If your ID looks like *rootNode.childNode*, the helper will look
-for a node named *rootNode* and it will append the *childNode* to it. If
-the root node doesn’t exist, it will create it.
-
-Link the AngularJS module’s controller file
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-To include the module’s controller file, you can use the
-NavHelperProvider. It contains a method that will load the given file.
-
-::
-
- [...]
- NavHelperProvider.addControllerUrl('<path_to_module_folder>/<module_name>.controller');
-
-This completes your module.js file.
-
-Create the controller, factory, directive, etc
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Creating the controller and other components is similar to the module.
-
-- First, add the define method.
-
-- Second, add the relative path to the module definition.
-
-- Last, create your methods as you usually do it with AngularJS.
-
-For example -
-
-::
-
- define(['<relative_path_to_module>/<module_name>.module'], function(module) {
- module.register.controller('ModuleCtrl', function($rootScope, $scope) {
- });
- });
-
-Add new application using DLUX modularity
------------------------------------------
-
-DLUX works as a Karaf based UI platform, where you can create a new
-Karaf feature of your UI component and install that UI applications in
-DLUX using blueprint. This page will help you to create and load a new
-application for DLUX. You don’t have to add new module in DLUX
-repository.
-
-Add a new OSGi blueprint bundle
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The OSGi Blueprint Container specification allows us to use dependency
-injection in our OSGi environment. Each DLUX application module
-registers itself via blueprint configuration. Each application will have
-its own blueprint.xml to place its configuration.
-
-1. Create a maven project to place blueprint configuration. For
- reference, take a look at topology bundle, present at
- https://github.com/opendaylight/dlux/tree/stable/boron/bundles/topology.
- All the existing DLUX modules' configurations are available under
- bundles directory of DLUX code.
-
-2. In pom.xml, you have to add a maven plugin to unpack your module code
- under generated-resources of this project. For reference, you can
- check pom.xml of dlux/bundles/topology at
- https://github.com/opendaylight/dlux/tree/stable/boron/bundles/topology.
- Your bundle will eventually get deployed in Karaf as feature, so your
- bundle should contain all your module code. If you want to combine
- module and bundle project, that should not be an issue either.
-
-3. Create a blueprint.xml configuration file under
- src/main/resources/OSGI-INF/blueprint. Below is the content of the
- blueprint.xml taken from topology bundles’s blueprint.xml. Any new
- application should create a blueprint.xml in following format -
-
-::
-
- <blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0">
- <reference id="httpService" availability="mandatory" activation="eager" interface="org.osgi.service.http.HttpService"/>
- <reference id="loader" availability="mandatory" activation="eager" interface="org.opendaylight.dlux.loader.DluxModuleLoader"/>
-
- <bean id="bundle" init-method="initialize" destroy-method="clean" class="org.opendaylight.dlux.loader.DluxModule">
- <property name="httpService" ref="httpService"/>
- <property name="loader" ref="loader"/>
- <property name="moduleName" value="topology "/>
- <property name="url" value="/src/app/topology"/>
- <property name="directory" value="/topology"/>
- <property name="requireJs" value="app/topology/topology.module"/>
- <property name="angularJs" value="app.topology"/>
- <property name="cssDependencies">
- <list>
- <value>http://yui.yahooapis.com/3.18.1/build/cssreset/cssreset-min.css</value>
- <value>src/app/topology/topology-custom.css</value>
- </list>
- </property>
- </bean>
- </blueprint>
-
-In above configuration, there are two references with id httpService and
-loader. These two beans will already be initialized by dlux-core, so any
-new application can use them. Without these two bean references, a new
-application will not be able to register.
-
-Next is the initialization of your application bean, which will be an
-instance of class org.opendaylight.dlux.loader.DluxModule. There are 5
-properties that you should provide in this bean besides the references
-of httpService and loader. Lets talk about those bean properties in
-little more detail.
-
-**moduleName** : Name of your module. This name should be unique in
-DLUX.
-
-**url**: This is the url via which RequireJS in DLUX will try to load
-your module JS/HTML files. Also, this is the url that browser will use
-to load the static HTML, JS or CSS files. RequireJS in DLUX has a base
-path of **src**, so all the url should start with /src so RequireJS and
-the browser can correctly find the files.
-
-**directory**: In your bundle’s pom.xml, you unpack your module code.
-This is the directory where your actual static files will reside. The
-above mentioned url is registered with httpService, so when browser
-makes a call to that url, it will be redirected to the directory
-mentioned here. In the above example, all the topology files are present
-under /topology directory and the browser/RequireJS can access those
-files with uri /src/app/topology.
-
-**requireJS**: This is the path to your RequireJS module. If you notice
-closely, you will see the initial path of RequireJS app/topology in the
-above example matches with the last part of url. This path will be be
-used by RequireJS. As mentioned above, we have kept **src** as base path
-in RequireJS, that is the exact reason that url start with /src.
-
-**angularJS**: name of your AngularJS module.
-
-**cssDependencies**: If the application has any external/internal css
-dependencies, then those can be added here. If you create your own css
-files, just point to those css files here. Use the url path that you
-mentioned above, so the browser can find your css file.
-
-OSGi understands blueprint.xml, once you will deploy your bundle in
-karaf (or you can create a new feature for your application), karaf will
-read your blueprint.xml and it will try to register your application
-with dlux. Once successful, if you refresh your dlux UI, you will see
-your application in left hand navigation bar of dlux.
-
-Yang Utils
-----------
-
-Yang Utils are used by UI to perform all CRUD operations. All of these
-utilities are present in yangutils.services.js file. It has following
-AngularJS factories -
-
-- **arrayUtils** – defines functions for working with arrays.
-
-- **pathUtils** – defines functions for working with xpath (paths to
- APIs and subAPIs). It divides xpath string to array of elements, so
- this array can be later used for search functions.
-
-- **syncFact** – provides synchronization between requests to and from
- OpenDaylight when it’s needed.
-
-- **custFunct** – it is linked with
- apiConnector.createCustomFunctionalityApis in yangui controller in
- yangui.controller.js. That function makes it possible to create some
- custom function called by the click on button in index.tpl.html. All
- custom functions are stored in array and linked to specific subAPI.
- When particular subAPI is expanded and clicked, its inputs (linked
- root node with its child nodes) are displayed in the bottom part of
- the page and its buttons with custom functionality are displayed
- also.
-
-- **reqBuilder** – Builds object in JSON format from input fields of
- the UI page. **Show Preview** button on Yang UI use this builder.
- This request is sent to OpenDaylight when button PUT or POST is
- clicked.
-
-- **yinParser** – factory for reading .xml files of yang models and
- creating object hierarchy. Every statement from yang is represented
- by a node.
-
-- **nodeWrapper** – adds functions to objects in tree hierarchy created
- with yinParser. These functions provide functionality for every type
- of node.
-
-- **apiConnector** – the main functionality is filling the main
- structures and linking them. Structure of APIs and subAPIs which is
- two level array - first level is filled by main APIs, second level is
- filled by others sub APIs. Second main structure is array of root
- nodes, which are objects including root node and its children nodes.
- Linking these two structures is creating links between every subAPI
- (second level of APIs array) and its root node, which must be
- displayed like inputs when subAPI is expanded.
-
-- **yangUtils** – some top level functions which are used by yangui
- controller for creating the main structures.
-
eman is composed of 3 Karaf features:
* ``eman`` incudes the YANG model and its implementation
* ``eman-api`` adds support for REST
- * ``eman-ui`` adds support for DLUX.
Developers will typically interface with ``eman-api``.
didm-developer-guide
distribution-version
distribution-test-features
- dlux
eman-developer-guide
fabric-as-a-service
infrautils-developer-guide
::
feature:install odl-nic-core-service-mdsal odl-nic-core odl-nic-console odl-nic-listeners
- feature:install odl-dlux-core odl-dluxapps-applications
-2. Start mininet topology and verify in DLUX Topology page for the nodes
- and link.
+2. Start mininet topology. (verification of topology can be done with the topology
+ URI using RESTCONF)
::
- and target implementation is assigned (``...OpenflowPluginProvider``)
-.. code:: yang
+.. code::
module openflow-provider {
yang-version 1;
provided by openflowjava, one plugin instance will orchestrate
multiple openflowjava modules)
-.. code:: yang
+.. code::
module openflow-provider-impl {
yang-version 1;
- output model
-.. code:: yang
+.. code::
leaf output-model {
type identityref {
- overlay topology with new nodes
-.. code:: yang
+.. code::
container node-info {
leaf node-topology {
- underlay topologies with original links
-.. code:: yang
+.. code::
list link-info {
key "link-topology input-model";
add another identity item to topology-correlation.yang file. For our
inventory-rendering model identity looks like this:
-.. code:: yang
+.. code::
identity inventory-rendering-model {
description "inventory-rendering.yang";
You can find API examples on `this wiki
page <https://wiki.opendaylight.org/view/Topology_Processing_Framework:Developer_Guide:REST_API_Specification>`__.
-
---------------
module: mef-services
+
::
+
+--rw mef-services
+--rw mef-service* [svc-id]
+--rw evc
+--rw svc-entity? mef-types:service-entity-type
module: mef-global
+
::
+
+--rw mef-global
+--rw svc-providers!
| +--rw svc-provider* [sp-id]
---------------
module: onf-core-network-module
+
::
+
+--rw forwarding-constructs
+--rw forwarding-construct* [uuid]
+--rw uuid string
+--rw forwardingDirection? onf-cnt:ForwardingDirection
augment /nt:network-topology/nt:topology/nt:node/nt:termination-point:
+
::
+
+--rw ltp-attrs
+--rw lpList* [uuid]
| +--rw uuid string
- The USC Manager handles configurations, high availability,
security, monitoring, and clustering support for USC.
-- USC UI
-
- - The USC UI is responsible for displaying a graphical user
- interface representing the state of USC in the OpenDaylight DLUX
- UI.
-
USC Channel APIs and Interfaces
-------------------------------
For VTN Java API documentation, please refer to:
https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/apidocs/index.html
-Once the Karaf distribution is up, install dlux and apidocs.
-
-::
-
- feature:install odl-dlux-core odl-dluxapps-applications odl-mdsal-apidocs
-
-Logging In
-''''''''''
-
-To Log in to DLUX, after installing the application:
-
-- Open a browser and enter the login URL as
- http://<OpenDaylight-IP>:8181/index.html
-
-.. note::
-
- Replace "<OpenDaylight-IP>" with the IP address of OpenDaylight
- based on your environment.
-
-- Login to the application with user ID and password credentials as
- admin.
-
-.. note::
-
- admin is the only default user available for DLUX in this release.
-
-- In the right hand side frame, click "Yang UI".
-
-YANG documentation for VTN Manager, please refer to:
-https://nexus.opendaylight.org/content/sites/site/org.opendaylight.vtn/boron/manager.model/apidocs/index.html
-
.. _vtn-coordinator:
VTN Coordinator
to define an extension for it so that the YANG statement parser can
recognize it.
-.. code:: yang
+.. code::
module semantic-version {
namespace "urn:opendaylight:yang:extension:semantic-version";
the bar module based on its semantic version. Notice how both modules
import the module with the semantic-version extension.
-.. code:: yang
+.. code::
module foo {
namespace foo;
...
}
-.. code:: yang
+.. code::
module bar {
namespace bar;
Let us show a more complex example of creating a NormalizedNode. First,
consider the following YANG module:
-.. code:: yang
+.. code::
module example-module {
namespace "opendaylight.org/example-module";
Diagnostics
~~~~~~~~~~~
-
--- /dev/null
+######################
+OpenDaylight Downloads
+######################
+
+Supported Releases
+==================
+
+Oxygen-SR1
+----------
+
+(Current Release)
+
+:Annoucement: https://www.opendaylight.org/about/news/blogs/opendaylight-releases-oxygen-with-new-p4-and-container-support
+:Original Release Date: March 22, 2018
+:Service Release Date: April 25, 2018
+
+:Downloads:
+ * `OpenDaylight Oxygen SR1 Tar
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.8.1/karaf-0.8.1.tar.gz>`_
+ * `OpenDaylight Oxygen SR1 Zip
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.8.1/karaf-0.8.1.zip>`_
+ * `OpenDaylight Oxygen SR1 RPM
+ <http://cbs.centos.org/repos/nfv7-opendaylight-81-release/x86_64/os/Packages/opendaylight-8.1.0-1.el7.noarch.rpm>`_
+ * `OpFlex
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/opflex/>`_
+
+:Documentation:
+ * :doc:`Getting Started Guide <odl-oxygen:getting-started-guide/index>`
+ * :doc:`Developers Guide <odl-oxygen:developer-guide/index>`
+ * :doc:`User Guide <odl-oxygen:user-guide/index>`
+ * :doc:`Installation Guide <odl-oxygen:getting-started-guide/installing_opendaylight>`
+ * :doc:`Using OpenDaylight with OpenStack <odl-oxygen:opendaylight-with-openstack/index>`
+ * :doc:`Release Notes <odl-oxygen:release-notes/index>`
+
+Nitrogen-SR3
+------------
+
+:Annoucement: https://www.opendaylight.org/blog/2017/09/26/opendaylight-introduces-nitrogen
+:Original Release Date: September 26, 2017
+:Service Release Date: May 11, 2018
+
+:Downloads:
+ * `OpenDaylight Nitrogen SR3 Tar
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.7.3/karaf-0.7.3.tar.gz>`_
+ * `OpenDaylight Nitrogen SR3 Zip
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/karaf/0.7.3/karaf-0.7.3.zip>`_
+ * `OpFlex
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/opflex/>`_
+
+:Documentation:
+ * :doc:`Getting Started Guide <odl-nitrogen:getting-started-guide/index>`
+ * :doc:`Developers Guide <odl-nitrogen:developer-guide/index>`
+ * :doc:`User Guide <odl-nitrogen:user-guide/index>`
+ * :doc:`Installation Guide <odl-nitrogen:getting-started-guide/installing_opendaylight>`
+ * :doc:`Using OpenDaylight with OpenStack <odl-nitrogen:opendaylight-with-openstack/index>`
+ * :doc:`Release Notes <odl-nitrogen:release-notes/index>`
+
+Carbon-SR4
+----------
+
+:Annoucement: https://www.opendaylight.org/what-we-do/current-release/carbon
+:Original Release Date: May 25, 2017
+:Service Release Date: April 27, 2018
+
+:Downloads:
+ * `OpenDaylight Carbon SR4 Tar
+ <https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/distribution-karaf/0.6.4-Carbon/distribution-karaf-0.6.4-Carbon.tar.gz>`_
+ * `OpenDaylight Carbon SR4 Zip
+ <https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/distribution-karaf/0.6.4-Carbon/distribution-karaf-0.6.4-Carbon.zip>`_
+ * `OpenDaylight Carbon SR4 RPM
+ <http://cbs.centos.org/repos/nfv7-opendaylight-64-release/x86_64/os/Packages/opendaylight-6.4.0-1.el7.noarch.rpm>`_
+ * `OpFlex
+ <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/opflex/>`_
+
+:Documentation:
+ * :doc:`Getting Started Guide <odl-carbon:getting-started-guide/index>`
+ * :doc:`Developers Guide <odl-carbon:developer-guide/index>`
+ * :doc:`User Guide <odl-carbon:user-guide/index>`
+ * :doc:`Installation Guide <odl-carbon:getting-started-guide/installing_opendaylight>`
+ * :doc:`Using OpenDaylight with OpenStack <odl-carbon:opendaylight-with-openstack/index>`
+ * :doc:`Release Notes <odl-carbon:release-notes/index>`
+
+Archived Releases
+=================
+
+* `OpenDaylight (Nitrogen and newer) <https://nexus.opendaylight.org/content/repositories/opendaylight.release/org/opendaylight/integration/karaf/>`_
+* `OpenDaylight (Carbon and earlier) <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/distribution-karaf/>`_
+* `NeXt UI <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/next/next/>`_
+* `VTN Coordinator <https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/vtn/distribution.vtn-coordinator/>`_
The Integration team is maintaining a Python based `tool
<https://github.com/opendaylight/integration-test/tree/master/tools/clustering/cluster-monitor>`_,
-that takes advantage of the above MBeans exposed via Jolokia, and the
-*systemmetrics* project offers a DLUX based UI to display the same
-information.
+that takes advantage of the above MBeans exposed via Jolokia.
.. _cluster_admin_api:
b. A message bus that provides a way for the various services and protocol
drivers to notify and communicate with one another.
-* If you’re interacting with OpenDaylight through DLUX or the REST APIs while
+* If you’re interacting with OpenDaylight through the REST APIs while
using the the OpenDaylight interfaces, the microservices architecture allows
you to select available services, protocols, and REST APIs.
:maxdepth: 1
introduction
- who_should_use
concepts_and_tools
installing_opendaylight
project-specific-guides/index
clustering
persistence_and_backup
security_considerations
+ what_to_do_with_odl
how-to-get-help
The OpenDaylight project is an open source platform for Software Defined
Networking (SDN) that uses open protocols to provide centralized, programmatic
-control and network device monitoring. Like many other SDN controllers,
-OpenDaylight supports OpenFlow, as well as offering ready-to-install network
-solutions as part of its platform.
+control and network device monitoring.
Much as your operating system provides an interface for the devices that
comprise your computer, OpenDaylight provides an interface that allows you to
-connect network devices quickly and intelligently for optimal network
-performance.
-
-It’s extremely helpful to understand that setting up your networking environment
-with OpenDaylight is not a single software installation. While your first
-chronological step is to install OpenDaylight, you install additional
-functionality packaged as Karaf features to suit your specific needs.
-
-Before walking you through the initial OpenDaylight installation, this guide
-presents a fuller picture of OpenDaylight’s framework and functionality so you
-understand how to set up your networking environment. The guide then takes you
-through the installation process.
+control and manage network devices.
What’s different about OpenDaylight
===================================
-Major distinctions of OpenDaylight’s SDN compared to traditional SDN options are
+Major distinctions of OpenDaylight’s SDN compared to other SDN options are
the following:
* A microservices architecture, in which a “microservice” is a particular
protocol or service that a user wants to enable within their installation of
the OpenDaylight controller, for example:
- * A plugin that provides connectivity to devices via the OpenFlow or BGP
- protocols
- * An L2-Switch or a service such as Authentication, Authorization, and
- Accounting (AAA).
-
-* Support for a wide and growing range of network protocols beyond OpenFlow,
- including SNMP, NETCONF, OVSDB, BGP, PCEP, LISP, and more.
-* Support for developing new functionality comprised of additional networking
- protocols and services.
-
-.. note:: A thorough understanding of the microservices architecture is
- important for experienced network developers who want to create new solutions
- in OpenDaylight. If you are new to networking and OpenDaylight, you most
- likely won’t design solutions, but you should comprehend the microservices
- concept to understand how OpenDaylight works and how it differs from other
- SDN programs.
-
-What you’ll find in this guide
-==============================
-
-To set up your environment, you first install OpenDaylight followed by the
-Apache Karaf features that offer the functionality you require. The OpenDaylight
-Getting Started Guide covers feature descriptions, OpenDaylight installation
-procedures, and feature installation.
+ * A plugin that provides connectivity to devices via the OpenFlow protocols
+ (openflowplugin).
+ * A platform service such as Authentication, Authorization, and Accounting
+ (AAA).
+ * A network service providing VM connectivity for OpenStack (netvirt).
+* Support for a wide and growing range of network protocols: OpenFlow, P4
+ BGP, PCEP, LISP, NETCONF, OVSDB, SNMP and more.
-The Getting Started Guide also includes other helpful information, with the
-following organization:
+* Model Driven Service Abstraction Layer (MD-SAL). Yang models play a key role
+ in OpenDaylight and are used for:
-#. An overview of OpenDaylight and common use models
-#. OpenDaylight concepts and tools
-#. OpenDaylight installation instructions
-#. OpenDaylight user interface
-#. Setting Up Cluster
-#. Persistence and Backup
-#. Security considerations
-#. How to get help
+ * Creating datastore schemas (tree based structure).
+ * Generating application REST API (RESTCONF).
+ * Automatic code generation (Java interfaces and Data Transfer Objects).
--- /dev/null
+.. _tsdr-hbase-install-guide:
+
+TSDR HBase Data Store Installation Guide
+========================================
+
+This document is for the user to install the artifacts that are needed
+for using HBase Data Store in Time Series Data Repository, which is
+a new feature available in OpenDaylight Lithium release.
+
+Overview
+--------
+
+The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a
+framework for collecting, storing, querying, and maintaining time series data
+in the OpenDaylight SDN controller. It contains the following services and
+components:
+
+ Data Collection Service
+ Data Storage Service
+ TSDR Persistence Layer with data stores as plugins
+ TSDR Data Stores
+ Data Query Service
+ Data Aggregation Service
+ Data Purging Service
+
+Data Collection Service handles the collection of time series data into TSDR
+and hands it over to Data Storage Service. Data Storage Service stores the data
+into TSDR through TSDR Persistence Layer. TSDR Persistence Layer provides
+generic Service APIs allowing various data stores to be plugged in. Data
+Aggregation Service aggregates time series fine-grained raw data into
+course-grained roll-up data to control the size of the data. Data Purging
+Service periodically purges both fine-grained raw data and course-granined
+aggregated data according to user-defined schedules.
+
+
+In Lithium, we implemented Data Collection Service, Data Storage Service, TSDR
+Persistence Layer, TSDR HBase Data Store, and TSDR H2 Data Store. Among these
+services and components, time series data is communicated using a common TSDR
+data model, which is designed and implemented for the abstraction of the time
+series data commonalities. With these functions, TSDR will be able to collect
+the data from the data sources and store them into one of the TSDR data stores:
+either HBase Data Store or H2 Data Store. We also provided a simple query
+command from Karaf console for the user to retrieve TSDR data from the data
+stores.
+
+A future release will contain Data Aggregation service, Data Purging Service,
+and a full-fledged Data Query Service with Norghbound APIs.
+
+
+Prerequisites for Installing TSDR HBase Data Store
+--------------------------------------------------
+
+The hardware requirements are the same as those for standard ODL controller
+installation.
+
+The software requirements for TSDR HBase Data Store are as follows:
+
+ The supported operating system for TSDR HBase Data Store is Linux. We do not
+ support TSDR HBase Data Store on Windows.
+ Besides the software that ODL requires, we also require HBase database
+ running on top of Hadoop single node.
+
+Preparing for Installation
+--------------------------
+
+Download HBase (version number to be finalized) from the following website.
+
+http://archive.apache.org/dist/hbase/hbase-0.94.15/
+
+
+Installing TSDR HBase Data Store
+--------------------------------
+
+Installing TSDR HBase Data Store contains two steps:
+
+ Installing HBase server, and
+ Installing TSDR HBase Data Store features from ODL Karaf console.
+
+This installation guide will only cover the first step. For installing TSDR
+HBase Data Store features, please refer to TSDR HBase Data Store User Guide.
+
+In Lithium, we only support HBase single node running together on the same
+machine as ODL controller. Therefore, follow the steps to download and install
+HBase server onto the same box as where ODL controller is running:
+
+ Create a folder in Linux operating system for the HBase server.
+
+For example, create an hbase directory under /usr/lib:
+
+ ::
+
+ mkdir /usr/lib/hbase
+
+Unzip the downloaded HBase server tar file.
+
+Run the following command to unzip the installation package:
+
+ ::
+
+ tar xvf <hbase-installer-name> /usr/lib/hbase
+
+Make proper changes in hbase-site.xml
+
+ .. Under <hbase-install-directory>/conf/, there is a hbase-site.xml.
+ .. Although it is not recommended, an experience user with HBase canmodify
+ .. the data directory for hbase server to store the data.
+
+ .. Modify the value of the property with name "hbase.rootdir" in the file
+ .. to reflect the desired file directory for storing hbase data.
+
+The following is an example of the file:
+
+ ::
+
+ <configuration>
+ <property>
+ <name>hbase.rootdir</name>
+ <value>file:///usr/lib/hbase/data</value>
+ </property>
+ <property>
+ <name>hbase.zookeeper.property.dataDir</name>
+ <value>/usr/lib/hbase/zookeeper</value>
+ </property>
+ </configuration>
+
+Verifying your Installation
+---------------------------
+
+After the HBase server is properly installed, start hbase server and hbase shell.
+
+ ::
+
+ start hbase server
+ cd <hbase-installation-directory>
+ ./start-hbase.sh
+
+ start hbase shell
+ cd <hbase-insatllation-directory>
+ ./hbase shell
+
+Post Installation Configuration
+-------------------------------
+
+Please refer to HBase Data Store User Guide.
+
+Upgrading From a Previous Release
+---------------------------------
+
+Lithium is the first release of TSDR. Upgrading is not applicable for TSDR Lithium release.
+
+Uninstalling HBase Data Store
+-----------------------------
+
+To uninstall TSDR HBase Data Store,
+
+.. code-block:: bash
+
+ stop hbase server
+ cd <hbase-installation-directory>
+ ./stop-hbase.sh
+
+To remove the file directory that contains the HBase server installation.
+
+.. code-block:: bash
+
+ rm -r <hbase-installation-directory>
--- /dev/null
+.. _tsdr-hsqldb-install-guide:
+
+TSDR HSQLDB Default Datastore Installation Guide
+================================================
+
+This document is for the user to install the artifacts that are needed
+for using Time Series Data Repository (TSDR) functionality in the ODL
+Controller by enabling the default HSQLDB Datastore. TSDR is new functionality
+added in OpenDaylight in Lithium Release.
+
+Overview
+--------
+
+In Lithium Release the time series data records of OpenFlow statistics are
+collected periodically and stored in a persistent store. For non-production
+usage, the bundled default datastore (HSQLDB) is utilized based on odl-tsdr-all
+feature installation. The TSDR records get persisted in HSQLDB store in
+<install folder>/tsdr/ folder by default.
+
+Installing TSDR with default HSQLDB datastore
+---------------------------------------------
+
+Once OpenDaylight distribution is up, from karaf console install the TSDR
+feature with default datastore (HSQLDB store used) can be installed by::
+
+ feature:install odl-tsdr-all
+
+
+This will install all dependency features (and can take sometime) before
+returning control to the console.
+
+Verifying your Installation
+---------------------------
+
+If the feature install was successful you should be able to see the following
+tsdr commands added::
+
+ tsdr:list
+
+
+Troubleshooting
+---------------
+
+Check the ../data/log/karaf.log for any exception related to TSDR or HSQLDB
+related features.
+
+Post Installation Configuration
+-------------------------------
+
+The feature installation takes care of automated configuration of the
+datasource by installing a file in
+<install folder>/etc named org.ops4j.datasource-metric.cfg.
+This contains the default location of <install folder>/tsdr where the HSQLDB
+datastore files are stored. If you want to change the default location of the
+datastore files to some other location update the last portion of the url
+property in the org.ops4j.datasource-metric.cfg and then restart the karaf
+container
+
+Upgrading From a Previous Release
+---------------------------------
+
+Lithium being the first release supporting TSDR functionality, only fresh
+installation is possible. However if you want to move to production usage by
+enabling the store HBase for TSDR usage, you can do it by uninstalling the TSDR
+with default HSQLDB datastore, restarting the Karaf container and then enabling
+the TSDR with HBase store as documented in tsdr-hbase-install.doc
+
+Uninstalling TSDR with default HSQLDB datastore
+-----------------------------------------------
+
+To uninstall the TSDR functionality with the default store, you need to do the
+following from karaf console
+
+.. code-block:: bash
+
+ feature:uninstall odl-tsdr-all
+ feature:uninstall odl-tsdr-core
+ feature:uninstall odl-tsdr-HSQLDB-persistence
+
+
+It's recommended to restart the Karaf container after uninstallation of the TSDR
+functionality with the default store
--- /dev/null
+.. _tsdr-install-guide:
+
+TSDR Installation Guide
+=======================
+
+This document is for the user to install the artifacts that are needed
+for using Time Series Data Repository (TSDR) functionality in the ODL
+Controller by enabling either an HSQLDB, HBase, or Cassandra Data Store.
+
+
+Overview
+--------
+
+The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a
+framework for collecting, storing, querying, and maintaining time series data
+in the OpenDaylight SDN controller. Please refer to the User Guide for the
+detailed description of the functionality of the project and how to use the
+corresponding features provided in TSDR.
+
+Pre Requisites for Installing TSDR
+----------------------------------
+
+The software requirements for TSDR HBase Data Store are as follows:
+
+* In the case when the user chooses HBase or Cassandra data store, besides the
+ software that ODL requires, we also require HBase and Cassandra database
+ running in single node deployment scenario.
+
+No additional software is required for the HSQLDB Data Stores.
+
+Preparing for Installation
+--------------------------
+
+* When using HBase data store, download HBase from the following website:
+
+ http://archive.apache.org/dist/hbase/hbase-0.94.15/
+
+* When using Cassandra data store, download Cassandra from the following website:
+
+ http://www.eu.apache.org/dist/cassandra/2.1.10/
+
+* No additional steps are required to install the TSDR HSQL Data Store.
+
+Installing TSDR Data Stores
+---------------------------
+
+Installing HSQLDB Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Once OpenDaylight distribution is up, from karaf console install the HSQLDB
+data store using the following command:
+
+ ::
+
+ feature:install odl-tsdr-hsqldb-all
+
+
+This will install hsqldb related dependency features (and can take sometime) as
+well as OpenFlow statistics collector before returning control to the console.
+
+
+Installing HBase Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Installing TSDR HBase Data Store contains two steps:
+
+#. Installing HBase server, and
+#. Installing TSDR HBase Data Store features from ODL Karaf console.
+
+In this release, we only support HBase single node running together on the same
+machine as OpenDaylight. Therefore, follow the steps to download and install
+HBase server onto the same machine as where OpenDaylight is running:
+
+#. Create a folder in Linux operating system for the HBase server
+
+ For example, create an hbase directory under ``/usr/lib``::
+
+ mkdir /usr/lib/hbase
+
+
+#. Unzip the downloaded HBase server tar file
+
+ Run the following command to unzip the installation package::
+
+ tar xvf <hbase-installer-name> /usr/lib/hbase
+
+
+#. Make proper changes in hbase-site.xml
+
+ #. Under <hbase-install-directory>/conf/, there is a ``hbase-site.xml``
+
+ Although it is not recommended, an experienced user with HBase can modify
+ the data directory for hbase server to store the data.
+
+ #. Modify the value of the property with name "hbase.rootdir" in the file to
+ reflect the desired file directory for storing hbase data.
+
+ The following is an example of the file::
+
+ <configuration>
+ <property>
+ <name>hbase.rootdir</name>
+ <value>file:///usr/lib/hbase/data</value>
+ </property>
+ <property>
+ <name>hbase.zookeeper.property.dataDir</name>
+ <value>/usr/lib/hbase/zookeeper</value>
+ </property>
+ </configuration>
+
+
+#. Start hbase server
+
+ .. code-block:: bash
+
+ cd <hbase-installation-directory>
+ ./start-hbase.sh
+
+#. Start hbase shell
+
+ .. code-block:: bash
+
+ cd <hbase-insatllation-directory>
+ ./hbase shell
+
+#. Start Karaf console
+
+#. Install hbase data store feature from Karaf console:
+
+ .. code-block:: bash
+
+ feature:install odl-tsdr-hbase
+
+
+Installing Cassandra Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Installing TSDR Cassandra Data Store contains two steps:
+
+#. Installing Cassandra server, and
+#. Installing TSDR Cassandra Data Store features from ODL Karaf console.
+
+ In this release, we only support Cassadra single node running together on the
+ same machine as OpenDaylight. Therefore, follow these steps to download and
+ install Cassandra server onto the same machine as where OpenDaylight is
+ running.
+
+#. Install Cassandra (latest stable version) by downloading the zip file and
+ untar the tar ball to cassandra/ directory on the testing machine.
+
+ .. code-block:: bash
+
+ mkdir cassandra
+ wget http://www.eu.apache.org/dist/cassandra/2.1.10/apache-cassandra-2.1.10-bin.tar.gz[2.1.10 is current stable version, it can vary]
+ mv apache-cassandra-2.1.10-bin.tar.gz cassandra/
+ cd cassandra
+ tar -xvzf apache-cassandra-2.1.10-bin.tar.gz
+
+
+#. Start Cassandra from cassandra directory
+
+ .. code-block:: bash
+
+ ./apache-cassandra-2.1.10/bin/cassandra
+
+#. Start cassandra shell
+
+ .. code-block:: bash
+
+ ./apache-cassandra-2.1.10/bin/cqlsh
+
+#. Install Cassandra data store feature from Karaf console
+
+ .. code-block:: bash
+
+ feature:install odl-tsdr-cassandra
+
+Verifying your Installation
+---------------------------
+
+After the TSDR data store is installed, no matter whether it is HBase data
+store, Cassandra data store, or HSQLDB data store, the user can verify the
+installation with the following steps.
+
+#. Verify if the following two TSDR commands are available from Karaf console:
+
+ .. code-block:: bash
+
+ tsdr:list
+ tsdr:purgeAll
+
+
+#. Verify if OpenFlow statistics data can be received successfully:
+
+ .. code-block:: bash
+
+ feature:install odl-tsdr-openflow-statistics-collector
+
+#. Run mininet to connect to ODL controller. For example, use the following
+ command to start a three node topology:
+
+ .. code-block:: bash
+
+ mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
+
+
+From Karaf console, the user should be able to retrieve the statistics data of
+OpenFlow statistics data from the console::
+
+ tsdr:list FLOWSTATS
+
+Troubleshooting
+^^^^^^^^^^^^^^^
+
+Check the ``../data/log/karaf.log`` for any exception related to TSDR features.
+
+Post Installation Configuration
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Post Installation Configuration for HSQLDB Data Store
+"""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+The feature installation takes care of automated configuration of the
+datasource by installing a file in <install folder>/etc named
+org.ops4j.datasource-metric.cfg. This contains the default location of
+<install folder>/tsdr where the HSQLDB datastore files are stored. If you want
+to change the default location of the datastore files to some other location
+update the last portion of the url property in the
+org.ops4j.datasource-metric.cfg and then restart the Karaf container.
+
+Post Installation Configuration for HBase Data Store
+""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+Please refer to HBase Data Store User Guide.
+
+Post Installation Configuration for Cassandra Data Store
+""""""""""""""""""""""""""""""""""""""""""""""""""""""""
+
+There is no post configuration for TSDR Cassandra data store.
+
+Upgrading From a Previous Release
+---------------------------------
+
+The HBase data store was supported in the previous release as well as in this
+release. However, we do not support data store upgrade for HBase data store.
+The user needs to reinstall TSDR and start to collect data in TSDR HBase
+datastore after the installation.
+
+HSQLDB and Cassandra are new data stores introduced in this release.
+Therefore, upgrading from previous release does not apply in these two data
+store scenarios.
+
+Uninstalling TSDR Data Stores
+-----------------------------
+
+To uninstall TSDR HSQLDB data store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To uninstall the TSDR functionality with the default store, you need to do the
+following from karaf console:
+
+.. code-block:: bash
+
+ feature:uninstall odl-tsdr-hsqldb-all
+ feature:uninstall odl-tsdr-core
+ feature:uninstall odl-tsdr-hsqldb
+ feature:uninstall odl-tsdr-openflow-statistics-collector
+
+It is recommended to restart the Karaf container after the uninstallation of
+the TSDR functionality with the default store.
+
+To uninstall TSDR HBase Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To uninstall the TSDR functionality with the HBase data store,
+
+* Uninstall HBase data store related features from karaf console
+
+ .. code-block:: bash
+
+ feature:uninstall odl-tsdr-hbase
+ feature:uninstall odl-tsdr-core
+
+* Stop hbase server
+
+ .. code-block:: bash
+
+ cd <hbase-installation-directory>
+ ./stop-hbase.sh
+
+* Remove the file directory that contains the HBase server installation:
+
+ .. code-block:: bash
+
+ rm -r <hbase-installation-directory>
+
+
+It is recommended to restart the Karaf container after the uninstallation of
+the TSDR data store.
+
+To uninstall TSDR Cassandra Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+To uninstall the TSDR functionality with the Cassandra store,
+
+* uninstall cassandra data store related features following from karaf console:
+
+ .. code-block:: bash
+
+ feature:uninstall odl-tsdr-cassandra
+ feature:uninstall odl-tsdr-core
+
+* stop cassandra database
+
+ .. code-block:: bash
+
+ ps auwx | grep cassandra
+ sudo kill pid
+
+* remove the cassandra installation files
+
+ .. code-block:: bash
+
+ rm <cassandra-installation-directory>
+
+It is recommended to restart the Karaf container after uninstallation of the
+TSDR data store.
-.. _tsdr-install-guide:
+.. _tsdr-guide:
TSDR Installation Guide
=======================
--- /dev/null
+.. _what_to_do_with_odl:
+
+*****************************
+What to Do with OpenDaylight
+*****************************
+
+OpenDaylight (ODL) is a modular open platform for customizing and automating
+networks of any size and scale.
+
+The following section provides links to documentation with examples of
+OpenDaylight deployment use cases.
+
+.. note:: If you are an OpenDaylight contributor, we encourage you to add links
+ to documentation with examples of interesting OpenDaylight deployment
+ use cases in this section.
+
+* `OPNFV Installation instructions (Apex) <http://artifacts.opnfv.org/apex/docs/installation-instructions/>`_
+* `Apex Wiki <https://wiki.opnfv.org/display/apex/Apex>`_
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
-Welcome to the OpenDaylight Handbook!
+Welcome to OpenDaylight Documentation
=====================================
-This handbook provides details on various aspects of OpenDaylight from the user
-guides to the developer guides and tries to act as a single point of contact
-for all documentation related articles in OpenDaylight. If you would like to
-contribute to the Handbook please refer to the :ref:`documentation-guide`.
+The OpenDaylight documentation site acts as a central clearinghouse for
+OpenDaylight project and release documentation. If you would like to contribute
+to documentation, refer to the :ref:`documentation-guide`.
-Content for OpenDaylight Users
+Getting Started with OpenDaylight
------------------------------
-The following content is intended for people who would like to deploy, use, or
-just learn more about OpenDaylight.
-
.. toctree::
:maxdepth: 1
+ downloads
release-notes/index
getting-started-guide/index
- user-guide/index
- opendaylight-with-openstack/index
+OpenDaylight User Guides
+-------------------------
-Content for OpenDaylight Developers
------------------------------------
+.. toctree::
+ :maxdepth: 1
-The Following content is intended for developers building applications or code
-on top of OpenDaylight, but who do not plan to modify OpenDaylight code
-itself.
+ user-guide/index
+
+OpenDaylight Developer Guides
+------------------------------
.. toctree::
:maxdepth: 1
javadoc
-Content for OpenDaylight Contributors
--------------------------------------
+OpenDaylight Project Documentation
+-----------------------------------
+
+Managed Projects
+~~~~~~~~~~~~~~~~~
+
+* :doc:`AAA Documentation <aaa:index>`
+* :doc:`BGPCEP Documentation <bgpcep:index>`
+* :doc:`Controller Documentation <controller:index>`
+* :doc:`COE Documentation <coe:index>`
+* :doc:`DAEXIM Documentation <daexim:index>`
+* :doc:`Genius Documentation <genius:index>`
+* :doc:`Infrautils Documentation <infrautils:index>`
+* :doc:`LISP Flow Mapping Documentation <lispflowmapping:index>`
+* :doc:`MD-SAL Documentation <mdsal:index>`
+* :doc:`NETCONF Documentation <netconf:index>`
+* :doc:`NetVirt Documentation <netvirt:index>`
+* :doc:`Neutron Documentation <neutron:index>`
+* :doc:`OpenFlowPlugin Documentation <openflowplugin:index>`
+* :doc:`OVSDB Documentation <ovsdb:index>`
+
+
+Self-Managed Projects
+~~~~~~~~~~~~~~~~~~~~~~
-The following content is intended for developers who either currently
-participate in the development of OpenDaylight or would like to start.
+
+OpenDaylight Contributor Guides
+--------------------------------
* :doc:`Gerrit Guide <lfdocs:gerrit>`
* :ref:`Infrastructure Guide <odl-infra>`
* :doc:`Integration Testing Guide <odl-integration-test:index>`
+* :doc:`Integration Distribution Guide <odl-integration-distribution:index>`
* :doc:`Integration Packaging Guide <odl-integration-packaging:index>`
-* :doc:`NetVirt Documentation <netvirt:index>`
.. toctree::
:maxdepth: 1
- submodules/releng/builder/docs/index
documentation
release-process/index
- submodules/genius/docs/index
- submodules/infrautils/docs/index
- submodules/openflowplugin/docs/index
- submodules/sfc/docs/index
+
+
.. Commenting the below out until we actually use it
.. Indices and tables
.. toctree::
:maxdepth: 1
- openstack-with-ovsdb
openstack-with-gbp
openstack-with-gbp-vpp
openstack-with-vtn
* SFC requires addition features for certain configurations
* SXP depends on TCP-MD5 on thus requires 64-bit Linux
* OpFlex requires Linux
-* DLUX requires a modern web browser to view the UI
* AAA when using federation has additional requirements for external tools
* VTN has components which require Linux
+++ /dev/null
-===
-AAA
-===
-
-Major Features
-==============
-
-For each top-level feature, identify the name, url, description, etc. User-facing features are used directly by end users.
-
-odl-aaa-shiro
--------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=aaa.git;a=blob_plain;f=features/shiro/features-aaa-shiro/src/main/features/features.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** ODL Shiro-based AAA implementation
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/aaa/job/aaa-csit-1node-authn-all-oxygen/
-
-odl-aaa-cert
-------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=aaa.git;a=blob;f=features/authn/features-aaa/src/main/features/features.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** MD-SAL based encrypted certificate management
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/aaa/job/aaa-csit-1node-authn-all-oxygen/
-
-odl-aaa-cli
-------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=aaa.git;a=blob;f=features/authn/features-aaa/src/main/features/features.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** Basic karaf CLI commands for interacting with AAA
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/aaa/job/aaa-csit-1node-authn-all-oxygen/
-
-
-Documentation
-=============
-
-Please provide the URL to each document at docs.opendaylight.org. If the document is under review, provide a link to the change in Gerrit.
-
-* **User Guide(s):**
-
- * :ref:`aaa-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`aaa-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- No.
-
-* Other security issues?
-
- N/A.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://jenkins.opendaylight.org/releng/view/aaa/job/aaa-sonar/>`_ (54% code coverage)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/aaa/>`_
-
-Migration
----------
-
-N/A.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- Yes.
-
-* Any API changes?
-
- No.
-
-* Any configuration changes?
-
- Some CLI commands were modified for security and ease of use purposes. Nothing else.
-
-Bugs Fixed
-----------
-
-* `AAA-165 <https://jira.opendaylight.org/projects/AAA/issues/AAA-165>`_ domain delete fails w/ java.lang.NoClassDefFoundError
-* `AAA-163 <https://jira.opendaylight.org/projects/AAA/issues/AAA-163>`_ implement "isEnabled" flag for user accounts
-* `AAA-160 <https://jira.opendaylight.org/projects/AAA/issues/AAA-160>`_ aaa-cli doesn't work
-* `AAA-158 <https://jira.opendaylight.org/projects/AAA/issues/AAA-158>`_ Repeated user creation fails with SQL query error
-* `AAA-156 <https://jira.opendaylight.org/projects/AAA/issues/AAA-156>`_ old password still works after changing password
-* `AAA-154 <https://jira.opendaylight.org/projects/AAA/issues/AAA-154>`_ H2 Database Username/Password should be configurable
-* `AAA-153 <https://jira.opendaylight.org/projects/AAA/issues/AAA-153>`_ remove "user" OOB user account
-* `AAA-149 <https://jira.opendaylight.org/projects/AAA/issues/AAA-149>`_ aaa-shiro-impl package names contain inconsistencies
-* `AAA-147 <https://jira.opendaylight.org/projects/AAA/issues/AAA-147>`_ odl-jolokia credentials should be centrally backed by AAA
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
-* `AAA-101 <https://jira.opendaylight.org/projects/AAA/issues/AAA-101>`_ token authentication fails intermittently
-
-* `Link to Open Bugs <https://jira.opendaylight.org/browse/AAA>`_
-
-End-of-life
-===========
-
-* N/A
-
-Standards
-=========
-
-* LDAP, JDBC, ActiveDirectory (less tested)
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/AAA:Oxygen:Release_Plan>`_
-* Describe any major shifts in release schedule from the release plan
-
- None.
+++ /dev/null
-=============================================
-Application-Layer Traffic Optimization (ALTO)
-=============================================
-
-odl-alto-release
-----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=alto.git;a=blob;f=alto-release-features/features-alto/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:**
- This feature loads all ALTO functionalities, including the simple Information
- Resource Directory service and the basic endpoint cost service (ECS), which is
- based on a simplified path computation engine (SPCE).
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/alto/job/alto-csit-1node-setup-all-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`ALTO User Guide <alto-user-guide>`
-
-* **Developer Guide(s):**
-
- * :ref:`ALTO Developer Guide <alto-developer-guide>`
-
-Security Considerations
-=======================
-
-Besides RESTCONF, ALTO also uses customized Jetty interfaces because YANG model
-is not fully compatible with formats specified in RFC 7285.
-
-The customized interfaces use port 8080 and are NOT protected by the AAA
-project. All resources exposed by customized interfaces are read-only.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.alto%3Aalto-parent>`_ 25.4%
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/alto/job/alto-csit-1node-setup-all-oxygen/>`_
-* The tests are using the OpenDaylight CSIT infrastructure.
-
- * How extensive was it? Not very extensive since the tests are customized to
- test certain functionalities.
- * What should be expected to work? The core modules (northbound and
- resourcepool) and also some basic components (simple-ird)
- * What has not be tested as much? Some basic components (simple-ecs and spce)
- and extended components (multicost, incremental update and RSA service).
-
-Migration
----------
-
-No migration is required from the Nitrogen release. Migration from earlier
-versions is not supported.
-
-Compatibility
--------------
-
-This release is compatible with the Nitrogen release, but not those before it.
-
-Bugs Fixed
-----------
-
-No bugs are fixed in this release.
-
-Known Issues
-------------
-
-Parallel query for simple-ecs service can lead to failures.
-
-* `Issue 16 <https://jira.opendaylight.org/browse/ALTO-16>`_
-
-End-of-life
-===========
-
-* Nothing deprecated, EOL.
-
-Standards
-=========
-
-* ALTO protocols are not compatible with YANG model
-* Message types for RFC 7285 have been implemented
-* ALTO project provides several basic services in RFC 7285
-* Work-in-progress Internet drafts for path-vector, multi-cost, incremental
- updates and RSA service are also scheduled but not fully implemented.
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/ALTO:Oxygen_Release_Plan>`_
+++ /dev/null
-===========
-BGP LS PCEP
-===========
-
-Major Features
-==============
-
-odl-bgpcep-bgp
---------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=features/bgp/features-bgp/pom.xml;h=f5acb8c44359fb258ef3b22c00269e48a091b7ee;hb=refs/heads/stable/oxygen
-* **Feature Description:** OpenDaylight Border Gateway Protocol (BGP) plugin.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-all-oxygen
-
-odl-bgpcep-bmp
---------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=features/bmp/features-bmp/pom.xml;h=6b195866c508ea053ecec4445973467b31aa7bfe;hb=refs/heads/stable/oxygen
-* **Feature Description:** OpenDaylight BGP Monitoring Protocol (BMP) plugin.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-all-oxygen
-
-odl-bgpcep-pcep
----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=tree;f=features/pcep/features-pcep;h=252a957bf6b8549ad53cedb45bbd76dca9ba7cb5;hb=refs/heads/stable/oxygen
-* **Feature Description:** OpenDaylight Path Computation Element Configuration Protocol (PCEP) plugin.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-all-oxygen
-
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`BGP User Guide <bgp-user-guide>`
- * :ref:`BGP Monitoring Protocol User Guide <bgp-monitoring-protocol-user-guide>`
- * :ref:`PCEP User Guide <pcep-user-guide>`
-
-* **Developer Guide(s):**
-
- * :ref:`BGP Developer Guide <bgp-developer-guide>`
- * :ref:`BGP Monitoring Protocol Developer Guide <bgp-monitoring-protocol-developer-guide>`
- * :ref:`PCEP Developer Guide <pcep-developer-guide>`
-
-Security Considerations
-=======================
-
-None Known - all protocol implements the TCP Authentication Option (TCP MD5)
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.bgpcep%3Abgpcep-aggregator>`_ (72.4%)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/bgpcep/>`_
-
-* `User features test <https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-gate-userfeatures-all-oxygen/>`_
-* `PCEP performance and scale tests <https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-throughpcep-only-oxygen/>`_
-* `BGP Application peer performance and scale tests <https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-throughpcep-all-oxygen/>`_
-* `BGP performance and scale test <https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-mixed-all-oxygen/>`_
-* `BGP clustering <https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-3node-periodic-bgpclustering-ha-only-oxygen/>`_
-
- The BGP extensions were tested manually with vendor's BGP router implementation or other software implementations (exaBGP, bagpipeBGP). Also, they are covered by the unit tests and automated system tests.
-
-Migration
----------
-
-* No additional migration steps needed.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
- Yes
-* Any API changes?
-* Any configuration changes?
- BGP CSS configuration is not longer supported.
- BMP CSS configuration is not longer supported.
- PCEP CSS configuration is not longer supported.
-
-Bugs Fixed
-----------
-
-* `List of bugs fixed since the previous release <https://jira.opendaylight.org/browse/BGPCEP-763?jql=project%20%3D%20BGPCEP%20AND%20status%20in%20(Resolved%2C%20Verified)%20AND%20created%20%3E%3D%202017-10-07%20AND%20created%20%3C%3D%202018-03-08>`_
-
-Known Issues
-------------
-
-* `List key known issues with workarounds <https://jira.opendaylight.org/browse/BGPCEP-762?jql=project%20%3D%20BGPCEP%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22)%20AND%20created%20%3E%3D%202017-10-07%20AND%20created%20%3C%3D%202018-03-08>`_
-
-End-of-life
-===========
-
-* BGP CSS Configuration.
-* PCEP CSS Configuration.
-* BMP CSS Configuration.
-
-Standards
-=========
-
-* :ref:`BGP Supported Capabilities <bgp-user-guide-supported-capabilities>`
-* :ref:`PCEP Supported Capabilities <pcep-user-guide-supported-capabilities>`
-* :ref:`BGP Monitoring Protocol Supported Capabilities <bgp-monitoring-protocol-user-guide-supported-capabilities>`
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/BGP_LS_PCEP:Oxygen_Release_Plan>`_
+++ /dev/null
-=======================================
-Bit Indexed Explicit Replication (BIER)
-=======================================
-
-odl-bier-all
-------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=bier.git;a=blob;f=features/features-bier/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** This is a summary feature containing the default functionalities provided by BIER project.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/bier/job/bier-csit-1node-basic-all-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`bier-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`bier-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * BIER project needs to get topology information via BGP-LS and BIER configuration via NETCONF.
-
-* Other security issues?
-
- * The required security issues are provided in the RESTCONF, NETCONF and BGP-LS projects.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.bier%3Abier>`_ 69.5%
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/bier/job/bier-csit-1node-basic-all-oxygen/>`_
-* Testing methodology. How extensive was it? What should be expected to work?
- What has not been tested as much?
-* There are unit tests and integration test available under folder "test" and system test in CSIT but the NETCONF
- interface is not tested and will be completed in next release.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- * No additional migration steps needed.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release? Yes.
-* Any API changes? Yes. Some BIER-TE APIs have been added and listed as following.
-bier/bierman/api/src/main/yang/bier-te-config-api.yang
-configure-te-node
-configure-te-label
-delete-te-babel
-delete-te-bsl
-delete-te-si
-delete-te-bp
-bier/oam/api/src/main/yang/bier-oam-api@2017-08-08.yang
-start-echo-request
-receive-echo-reply
-
-* Any configuration changes? None.
-
-Bugs Fixed
-----------
-
-* None.
-
-Known Issues
-------------
-
-* None.
-
-End-of-life
-===========
-
-* None.
-
-Standards
-=========
-
-* `Multicast using Bit Index Explicit Replication <https://datatracker.ietf.org/doc/draft-ietf-bier-architecture>`_
-* `YANG Data Model for BIER Protocol <https://datatracker.ietf.org/doc/draft-ietf-bier-bier-yang>`_
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/BIER:Oxygen:Release_Plan>`_
-* No major changes.
+++ /dev/null
-====================================
-COE (Container Orchestration Engine)
-====================================
-
-COE(Container Orchestration Engine) project aims at developing a framework for
-integrating Container Orchestration Engine (like Kuberenetes) and OpenDaylight.
-OpendayLight Oxygen Coe provides following modules --
-
-* **odlovs-cni plugin** A custom Kubernetes CNI Plugin developed for OpenDaylight.
-* **watcher** A Kubernetes API watcher module which can communicate Kubernetes events to OpenDaylight.
-* **coe-northbound** Module that provides the models necessary for consuming the Kubernetes events.
-
-Major Features
-==============
-
-* **Features URL:** https://git.opendaylight.org/gerrit/gitweb?p=coe.git;a=blob;f=features/pom.xml;hb=stable/oxygen
-
-odl-coe-api
------------
-
-* **Feature Description:** This feature provides all APIs provided by
- COE project for downstream consumers.
-
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Tests:**
- * WIP CSIT patch- https://git.opendaylight.org/gerrit/#/c/68920/
- * Jenkins Job Patch - https://git.opendaylight.org/gerrit/#/c/67227/
- * Patches to enable Vagrant for CSIT VMs - https://git.opendaylight.org/gerrit/#/c/68856/
-
-
-New capabilities and enhancements added in Oxygen
-=================================================
-
-Planned new capability added
-----------------------------
-
-* :doc:`/submodules/netvirt/docs/specs/coe-integration`
-
-
-Enhancements added to project
------------------------------
-
-#. L2 support for PODs
-#. L3 support for PODs
-
-
-Documentation
-=============
-
-* **Installation Guide(s):**
-
- * N/A
-
-* **User Guide(s):**
-
- * N/A
-
-* **Developer Guide(s):**
-
- * :doc:`Developer Guide </submodules/coe/docs/index>`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * No
-
-* Other security issues?
-
- * N/A
-
-Quality Assurance
-=================
-
-* `Sonar Report <https://sonar.opendaylight.org/projects?search=coe&sort=-analysis_date>`_
-
-* Other manual testing and QA information
-
- * CSIT activities are all in progress.
- * Manual testing is done with integrating with 3 node Kubernetes cluster on stable\oxygen distribution.
-
-* Testing methodology. How extensive was it? What should be expected to work?
- What hasn't been tested as much?
-
- * Functionality and System Tests with moderate scale is only tested
- * Scale tests yet to start
-
-Migration
----------
-
-* N/A
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- * Functionality is fully backwards compatible.
-
-* Any API changes?
-
- * No
-
-* Any configuration changes?
-
- * No
-
-Bugs Fixed
-----------
-
-* COE was in basic development phase in Oxygen, and hence no external bugs have been filed.
-
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- * None
-
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this
- release
-
- * N/A
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- * N/A
-
-Release Mechanics
-=================
-
-* `Release plan <https://wiki.opendaylight.org/view/Coe:Oxygen:Release_Plan>`_
-
-* Describe any major shifts in release schedule from the release plan
-
- * N/A
+++ /dev/null
-==========
-controller
-==========
-
-Major Features
-==============
-
-odl-mdsal-broker
-----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=controller.git;a=blob;f=features/mdsal/odl-mdsal-broker/pom.xml
-* **Feature Description:** Core MD-SAL implementations.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/controller/job/controller-csit-verify-3node-clustering/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`User Guide <controller-user-guide>`
-
-* **Developer Guide(s):**
-
- * :ref:`controller-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * Yes, akka uses port 2550 and by default communicates with unencrypted, unauthenticated messages. Securing akka communication isn't described here, but those concerned should look at the "Configuring SSL/TLS for Akka Remoting" section at http://doc.akka.io/docs/akka//2.4.17/scala/remoting.html.
-
-* Other security issues?
-
- * No
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://jenkins.opendaylight.org/releng/view/controller/job/controller-sonar/>`_ (60%)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/controller/>`_
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- Yes, no specific steps needed.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- * Yes
-
-* Any API changes?
-
- * No
-
-* Any configuration changes?
-
- * No
-
-Bugs Fixed
-----------
-
-* `CONTROLLER-1791 <https://jira.opendaylight.org/browse/CONTROLLER-1791>`_ member-1-shard-inventory-operational should not be in default clustering config
-* `CONTROLLER-1793 <https://jira.opendaylight.org/browse/CONTROLLER-1793>`_ Exceptions in listener threads are going to stdout instead of karaf.log
-* `CONTROLLER-1798 <https://jira.opendaylight.org/browse/CONTROLLER-1798>`_ ShardManager will miss sending a PeerAddressResolved message to local shards when UpdateSchemaContext comes after MemberUp
-* `CONTROLLER-1799 <https://jira.opendaylight.org/browse/CONTROLLER-1799>`_ Archetype should self test during Maven build
-* `CONTROLLER-1809 <https://jira.opendaylight.org/browse/CONTROLLER-1809>`_ Failed to restart all blueprint containers within 5 minutes
-* `CONTROLLER-1812 <https://jira.opendaylight.org/browse/CONTROLLER-1812>`_ DOMForwardedWriteTransaction infinite loop on cancel after exception
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- * None
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this
- release
-
- * The DataChangeListener interface was previously deprecated and is scheduled for removal
- in the next release, Flourine. All users of this interface must be converted to the
- DataTreeChangeListener interface.
-
- * The config subsystem was previously deprecated and is scheduled for removal
- in the next release, Flourine. All projects still using the config subsystem
- must be converted to use Blueprint.
-
- * The controller EntityOwnershipService interface was previously deprecated and is
- scheduled for removal in the next release, Flourine. All users of this interface must be
- converted to the mdsal EntityOwnershipService interface.
-
- * The controller liblldp module has been moved to the openflowplugin project and will be
- removed from the controller project in Flourine.
-
- * Various other APIs and classes in the controller project that have been long since
- deperecated may be removed in Flourine.
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- * None
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/OpenDaylight_Controller:Oxygen:Release_Plan>`_
+++ /dev/null
-==================
-Data Export/Import
-==================
-
-Major Features
-==============
-
-odl-daexim
-----------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=daexim.git;a=blob;f=features/odl-daexim/src/main/feature/feature.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** This is a wrapper feature which includes all
- the sub features provided by daexim project.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** `Single node <https://jenkins.opendaylight.org/releng/view/daexim/job/daexim-csit-1node-basic-only-oxygen/>`_. `Three node cluster <https://jenkins.opendaylight.org/releng/view/daexim/job/daexim-csit-3node-clustering-basic-only-oxygen/>`_.
-
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`Data Export/Import User Guide <daexim-user-guide>`
-
-* **Developer Guide(s):**
-
- * :ref:`Data Export/Import Developer Guide <daexim-dev-guide>`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * No
-
-* Other security issues?
-
- * N/A
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.daexim%3Adaexim>`_
-* Code coverage is 78.1%.
-* There are extensive unit-tests in the code.
-
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- * Migration should work across all releases.
-
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release? Yes
-* Any API changes? Yes. Added ability to export data on only one node. Details in yang module.
-* Any configuration changes? No.
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
- * All known bugs have been resolved.
-
-Known Issues
-------------
-
-* None.
-* `Current list of bugs <https://jira.opendaylight.org/projects/DAEXIM/issues/?filter=allopenissues>`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in
- this release
-
- * None
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- * None
-
-Release Mechanics
-=================
-
-* Describe any major shifts in release schedule from the release plan
-
- * None
+++ /dev/null
-========================
-Integration/Distribution
-========================
-
-Major Features
-==============
-
-odl-integration-all
--------------------
-
-* **Gitweb URL:** https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/singles/odl-integration-all/pom.xml;hb=refs/heads/stable/oxygen
-* **Description:** An aggregate feature grouping all user-facing ODL features
- which can be installed together without Karaf becoming unusable or without port conflicts.
-* **Top Level:** Yes.
-* **User Facing:** Yes, but not intended for production use (only for testing purposes).
-* **Experimental:** No.
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/job/distribution-deploy-oxygen
-
-odl-integration-compatible-with-all
------------------------------------
-
-* **Gitweb URL:** https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/singles/odl-integration-compatible-with-all/pom.xml;hb=refs/heads/stable/oxygen
-* **Description:** An aggregate feature grouping all user-facing ODL features
- which are not pro-active and which (as a group) should be compatible with most other ODL features.
-* **Top Level:** Yes.
-* **User Facing:** Yes, but not intended for production use (only for testing purposes).
-* **Experimental:** No.
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/job/distribution-csit-1node-userfeatures-all-oxygen
-
-odl-distribution-version
-------------------------
-
-* **Gitweb URL:** https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/singles/odl-distribution-version/pom.xml;hb=refs/heads/stable/oxygen
-* **Description:** Allows NETCONF/RESTCONF users to determine the version of ODL they are communicating with.
-* **Top Level:** Yes.
-* **User Facing:** Yes.
-* **Experimental:** No.
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/job/distribution-csit-1node-userfeatures-all-oxygen
-
-Karaf 4 distribution archive
-----------------------------
-* **Gitweb URL:** https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=karaf/pom.xml;hb=refs/heads/stable/oxygen
-* **Description:** Zip or tar.gz; when extracted, a self-consistent ODL installation is created.
-* **Top Level:** Yes.
-* **User Facing:** Yes.
-* **Experimental:** No.
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/job/distribution-deploy-oxygen
-
-Documentation
-=============
-
-* **Getting Started Guide**
-
- * :ref:`Clustering scripts <getting-started-clustering-scripts>`
- * :ref:`Distribution version <getting-started-opendaylight-version>`
-
-* **User Guide:**
-
- * :ref:`Distribution version <user-guide-dist-version>`
-
-* **Developer Guide**
-
- * :ref:`Test features <developer-guide-dist-test-features>`
- * :ref:`Distribution version <developer-guide-dist-version>`
-
-Security Considerations
-=======================
-
-* Karaf 4 exposes ssh console on port 8101.
- The security basically basically the same as in upstream Karaf of corresponding versions,
- except library version overrides implemented in odlparent:karaf-parent.
-
- See :ref:`securing-karaf`
-
-Quality Assurance
-=================
-
-* CSIT job: https://jenkins.opendaylight.org/releng/job/distribution-csit-1node-userfeatures-all-oxygen
-* No additional manual testing was needed.
-
-Migration
----------
-
-* Version feature works exactly the same as in Nitrogen.
- After migration the versions are set to the new default, configurable in runtime or via configfile.
-
-Compatibility
--------------
-
-* Version feature works exactly the same as in Nitrogen.
-* Test features change every release but these are only intended for distribution test.
-
-Bugs Fixed
-----------
-
-* `INTDIST-92 <https://jira.opendaylight.org/browse/INTDIST-92>`_
-
-** odl-distribution-version contains list of bundles instead of nice feature dependency.
-
-* `ODLPARENT-142 <https://jira.opendaylight.org/browse/ODLPARENT-142>`_
-
-** Karaf-plugin packages mysql-connector-java.
-
-Known Issues
-------------
-
-* `ODLPARENT-110 <https://jira.opendaylight.org/browse/ODLPARENT-110>`_
-
-** Successive feature installation from karaf4 console causes bundles refresh.
-
-*** **Workaround:**
-
- * Use --no-auto-refresh option in the karaf feature install command.
-
- .. code:: bash
-
- feature:install --no-auto-refresh odl-netconf-topology
-
- * List all the features you need in the karaf config boot file.
- * Install all features at once in console, for example:
-
- .. code:: bash
-
- feature:install odl-restconf odl-netconf-mdsal odl-mdsal-apidocs odl-clustering-test-app odl-netconf-topology
-
-* `ODLPARENT-113 <https://jira.opendaylight.org/browse/ODLPARENT-113>`_
-
-** The ssh-dss method is used by Karaf SSH console, but no longer supported by clients such as OpenSSH.
-
-*** **Workaround:**
-
- * Use the bin/client script, which uses karaf:karaf as the default credentials.
- * Use this ssh option:
-
- .. code:: bash
-
- ssh -oHostKeyAlgorithms=+ssh-dss -p 8101 karaf@localhost
-
-** After restart, Karaf is unable to re-use the generated host.key file.
-
-*** **Workaround:** Delete the etc/host.key file before starting Karaf again.
-
-End-of-life
-===========
-
-* Version feature is deprecated and will be removed in Flourine release.
-
-Standards
-=========
-
-No standard implemented directly (see upstream projects).
-
-Release Mechanics
-=================
-
-* `Release plan <https://wiki.opendaylight.org/view/Integration/Distribution/Oxygen_Release_Plan>`_
+++ /dev/null
-====
-Dlux
-====
-
-Major Features
-==============
-
-odl-dlux-core
-------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=dlux.git;a=blob;f=features/odl-dlux-core/pom.xml;h=8226826118c376b79924327acc656945938fcb14;hb=refs/heads/stable/oxygen
-* **Feature Description:** Core DLUX functionality
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-Documentation
-=============
-
-* **Developer Guide(s):**
-
- * `Dlux Getting Started <https://wiki.opendaylight.org/view/OpenDaylight_dlux:Getting_started>`_
-
-Security Considerations
-=======================
-
-* There are no security issues found.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=72613>`_
-* GUI is tested mostly manually, CSITs are on the way.
-
-Migration
----------
-
-* All applications are moved from Dlux project to DluxApps. Only odl-dlux-core feature remains.
-
-Compatibility
--------------
-
-* Release is compatible with previous.
-
-Bugs Fixed
-----------
-
-https://jira.opendaylight.org/browse/DLUX-115?jql=project%20%3D%20DLUX%20AND%20resolution%20in%20(Done)
-
-Known Issues
-------------
-
-* `Link to Open Bugs <https://jira.opendaylight.org/projects/DLUX/issues/DLUX-67?filter=allopenissues>`_
-
-End-of-life
-===========
-
-* N/A
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- * N/A
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/OpenDaylight_dlux:Oxygen_Release_Plan>`_
+++ /dev/null
-========
-DluxApps
-========
-
-Major Features
-==============
-
-odl-dluxapps-nodes
-------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=dluxapps.git;a=blob;f=features/odl-dluxapps-nodes/pom.xml;h=6537095c40efaa4edc62ef8da13c029420e0198b;hb=refs/heads/stable/oxygen
-* **Feature Description:** Application displays list of nodes in openflow (flow:1) topology.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-dluxapps-topology
----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=dluxapps.git;a=blob;f=features/odl-dluxapps-topology/pom.xml;h=bbdb1350db72a6db6bd112cbc5e413b8a428788d;hb=refs/heads/stable/oxygen
-* **Feature Description:** Basic topology application. Displays nodes and links from openflow (flow:1) topology.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-dluxapps-yangman
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=dluxapps.git;a=blob;f=features/odl-dluxapps-yangman/pom.xml;h=c7ed37b942fb9b66feccafec6834c555568f0e30;hb=refs/heads/stable/oxygen
-* **Feature Description:** GUI for data manipulation in controller. Generates forms based on loaded Yang models.
- User can interact with controller without knowledge of Yang models, test them, etc. Replacement of YangUI app.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/dluxapps/job/dluxapps-csit-1node-yangman-all-oxygen/
-
-odl-dluxapps-yangui
--------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=dluxapps.git;a=blob;f=features/odl-dluxapps-yangui/pom.xml;h=8a94f323a4590a64aeb8ded162cd539fbc328b9e;hb=refs/heads/stable/oxygen
-* **Feature Description:** Previous version of YangUI. Will be removed in next release.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-dluxapps-yangvisualizer
----------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=dluxapps.git;a=blob;f=features/odl-dluxapps-yangvisualizer/pom.xml;h=0697a5427261df4a391a70908a794ac3a9614bcd;hb=refs/heads/stable/oxygen
-* **Feature Description:** Topology-like visualization of Yang models loaded in controller.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-Documentation
-=============
-
-* **Developer Guide(s):**
-
- * `DluxApps Developer Guide <https://wiki.opendaylight.org/view/DluxApps:DeveloperGuide>`_
-
-Security Considerations
-=======================
-
-* There are no security issues found.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=72613>`_
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/dluxapps/search/?q=dluxapps-csit>`_
-* GUI is tested mostly manually, CSITs are on the way.
-
-Migration
----------
-
-* All applications are moved from Dlux project to DluxApps. Also feature names
- changed, so instead odl-dlux-\* use odl-dluxapps-\*. Everything else works same.
-
-Compatibility
--------------
-
-* Release is compatible with previous.
-* API changes are in feature names - odl-dlux-\* changes to odl-dluxapps-\*
-
-Bugs Fixed
-----------
-
-https://jira.opendaylight.org/browse/DLUXAPPS-29?jql=project%20%3D%20DLUXAPPS%20AND%20resolution%20in%20(Done)
-
-Known Issues
-------------
-
-* `Link to Open Bugs <https://jira.opendaylight.org/projects/DLUXAPPS/issues/DLUXAPPS-25?filter=allopenissues>`_
-
-End-of-life
-===========
-
-* odl-dluxapps-yangui - deprecated
-
-Standards
-=========
-
-* List of standrads implemented and to what extent
-
- * N/A
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/DluxApps:Oxygen_Release_Plan>`_
-* Yang UI not removed
+++ /dev/null
-======================
-Groupbasedpolicy (GBP)
-======================
-
-Major Features
-==============
-
-* GBP UI - Groupbasedpoilicy User Interface
-* Neutron Provider - maps neutron configuration to GBP service model
-* FaaS Renderer - maps GBP service model to the common abstraction logical network models of the Fabric As A Service
-* IOS-XE Renderer - maps GBP service model to IOS-XE based devices
-* IOvisor Renderer - maps GBP service model to agents of the IOVisor Linux Foundation project
-* Netconf Renderer - maps GBP service model to NETCONF based network elements
-* OpenFlow Overlay Renderer - enable network virtualization behavior using OpenFlow
-* SXP Distribution Service - enables SGT Exchange Protocol
-* VPP Renderer - enable network virtualization behavior for VPP devices
-
-odl-groupbasedpolicy-ofoverlay
-------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-ofoverlay/src/main/feature/features.xml;h=cd8aa7f1c4a08cc4d197135674d29806f71a886e;hb=refs/heads/stable/oxygen
-* **Feature Description:** Feature can be added to the base to enable a Network Virtualization behavior using OpenFlow
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-csit-1node-3-node-all-oxygen/
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-csit-1node-6node-all-oxygen/
-
-odl-groupbasedpolicy-iovisor
-----------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-iovisor/src/main/feature/features.xml;h=9c3df4b13a08a90d6e9fb0d32adc1eea7520d4af;hb=refs/heads/stable/oxygen
-* **Feature Description:** This renderer maps GBP service model to agents of the IOVisor Linux Foundation project
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-
-odl-groupbasedpolicy-neutronmapper
-----------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-neutronmapper/src/main/feature/features.xml;h=072eb849b39c4399863241818495ad460fb41663;hb=refs/heads/stable/oxygen
-* **Feature Description:** This renderer maps Neutron northbound configuration to GBP service model
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-groupbasedpolicy-neutron-and-ofoverlay
-------------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-neutron-and-ofoverlay/src/main/feature/features.xml;h=57c0b759454d00aa97a18e82b31168b37b74908d;hb=refs/heads/stable/oxygen
-* **Feature Description:** Neutron and OpenFlow Overlay
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-csit-1node-3-node-all-oxygen/
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-csit-1node-6node-all-oxygen/
-
-odl-groupbasedpolicy-vpp
-------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-vpp/src/main/feature/features.xml;h=05c6a72e95aa9f51c98f466da77569ffc4d9d012;hb=refs/heads/stable/oxygen
-* **Feature Description:** This renderer maps GBP service model to VPP devices
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-groupbasedpolicy-neutron-vpp-mapper
----------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-neutron-vpp-mapper/src/main/feature/features.xml;h=394dd02b54093f4c8767889c3935cb1c4a18c45a;hb=refs/heads/stable/oxygen
-* **Feature Description:** Neutron Northbound services for VPP renderer
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-groupbasedpolicy-ui
------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=tree;f=features/odl-groupbasedpolicy-ui;h=af30b7c9fc6d20de755d071b2d2e3da556d7b4a5;hb=refs/heads/stable/oxygen
-* **Feature Description:** Groupbasedpolicy User Interface
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-groupbasedpolicy-ip-sgt-distribution-service
-------------------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-ip-sgt-distribution-service/src/main/feature/features.xml;h=f421db3463d86751dde6a161466db309bc7e33a7;hb=refs/heads/stable/oxygen
-* **Feature Description:** SXP Distribution Service
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-groupbasedpolicy-ios-xe
----------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-ios-xe/src/main/feature/features.xml;h=b2498a4da528d8f43da84778516ba0677a0fbafe;hb=refs/heads/stable/oxygen
-* **Feature Description:** This renderer maps GBP service model to IOS-XE devices
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-groupbasedpolicy-sxp-ep-provider
-------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-sxp-ep-provider/src/main/feature/features.xml;h=4b3aa65f93776134d75e7c76305ca23300043f98;hb=refs/heads/stable/oxygen
-* **Feature Description:** SXP integration: Endpoint provider
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-groupbasedpolicy-sxp-ise-adapter
-------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=groupbasedpolicy.git;a=blob;f=features/odl-groupbasedpolicy-sxp-ise-adapter/src/main/feature/features.xml;h=14559f62741cee2809f92c43a27eb517a5fbef79;hb=refs/heads/stable/oxygen
-* **Feature Description:** SXP integration: ISE adapter
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-Documentation
-=============
-
-* **Installation Guide(s):**
-
- * `Groupbasedpolicy Installation Guide <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Installation_guide>`_
-
-* **User Guide(s):**
-
- * :ref:`gbp-user-guide`
-
-Security Considerations
-=======================
-
-* No other external interfaces than RESTCONF
-* No known security issues
-
-Quality Assurance
-=================
-
-`Sonar report (64.3%) <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.groupbasedpolicy%3Agroupbasedpolicy.project>`_
-
-Groupbasedpolicy CSIT:
-
-* https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-csit-1node-3-node-all-oxygen/
-* https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-csit-1node-6node-all-oxygen/
-* https://jenkins.opendaylight.org/releng/view/groupbasedpolicy/job/groupbasedpolicy-csit-3node-clustering-all-oxygen/
-
-Other manual testing and QA information
-
-* GBP devstack demo
-* GBP-SFC demo
-* VPP demo
-
-Guides about how to run demo can be found on GBP wiki under `Demo <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Consumability/Demo>`_
-
-Migration
----------
-
-Migration from previous releases is not supported.
-
-Compatibility
--------------
-* Is this release compatible with the previous release?
-
- Yes
-
-* Any API changes?
-
- N/A
-
-
-* Any configuration changes?
-
- N/A
-
-Bugs Fixed
-----------
-
-* `Fixed Bugs <https://jira.opendaylight.org/issues/?jql=project%20%3D%20GBP%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Resolved%20AND%20created%20%3E%3D%202017-08-14%20AND%20created%20%3C%3D%202018-03-07>`_
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- N/A
-
-* `Open Bugs <https://jira.opendaylight.org/browse/GBP-289?jql=project%20%3D%20GBP%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Open>`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this release
-
- N/A
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- N/A
-
-Release Mechanics
-=================
-
-* `Release plan <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Oxygen/Release_plan>`_
-
-* Describe any major shifts in release schedule from the release plan
-
- N/A
+++ /dev/null
-========================================================
-Genius (Generic Network Interface, Utilities & Services)
-========================================================
-
-Genius project provides Generic Network Interfaces, Utilities & Services. Any
-ODL application can use these to achieve interference-free co-existence with
-other applications using Genius. OpendayLight Carbon Genius provides following
-modules --
-
-* **Interface (logical port) Manager** allows bindings/registration of
- multiple services to logical ports/interfaces
-* **Overlay Tunnel Manager** creates and maintains overlay tunnels between
- configured tunnel endpoints
-* **Aliveness Monitor** provides tunnel/nexthop aliveness monitoring services
-* **ID Manager** generates cluster-wide persistent unique integer IDs
-* **MD-SAL Utils** provides common generic APIs for interaction with MD-SAL
-* **Resource Manager** provides a resource sharing framework for applications
- sharing common resources e.g. table-ids, group-ids etc.
-* **FCAPS Application** generates various alarms and counters for the different
- genius modules
-* **FCAPS Framework** module collectively fetches all data generated by fcaps
- application. Any underlying infrastructure can subscribe for its events to
- have a generic overview of the various alarms and counters
-
-Major Features
-==============
-
-* **Features URL:** https://git.opendaylight.org/gerrit/gitweb?p=genius.git;a=blob_plain;f=features/genius-features/pom.xml
-
-odl-genius
-----------
-
-* **Feature Description:** This feature provides all functionalities provided by
- genius modules, including interface manager, tunnel manager, resource manager
- and ID manager and MDSAL Utils. It includes Genius APIs and implementation.
-
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Tests:**
-
- * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-oxygen/
-
- * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-3node-upstream-all-oxygen/
-
-odl-genius-rest
----------------
-
-* **Feature Description:** This feature includes RESTCONF with 'odl-genius'
- feature.
-
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Tests:**
-
- * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-oxygen/
-
- * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-3node-upstream-all-oxygen/
-
-odl-genius-api
----------------
-
-* **Feature Description:** This feature includes API for all the functionalities
- provided by Genius.
-
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Tests:**
-
- * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-oxygen/
-
- * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-3node-upstream-all-oxygen/
-
-odl-genius-fcaps-application
-----------------------------
-
-* **Feature Description:** includes genius FCAPS application.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Tests:** None
-
-odl-genius-fcaps-framework
---------------------------
-
-* **Feature Description:** includes genius FCAPS Framework.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Tests:** None
-
-
-New capabilities and enhancements added in Oxygen
-=================================================
-
-Planned new capability added
-----------------------------
-
-* :doc:`/submodules/genius/docs/specs/itm-scale-improvements`
-
- .. note:: Some patches are under review, to be merged before Oxygen SR1
-
-
-Other enhancements added to project
------------------------------------
-
-#. Using new ManagedNewTransactionRunner utility where there is a DataBroker
-#. Using new FutureRpcResults utility in every RPC
-#. Migrate all users of @Deprecated genius DJC to infrautils JC
-#. Switch to using new infrautils Cache API instead of using ConcurrentMap
-#. Migrate all users of @Deprecated Data Store Listeners to new ones
-
-
-Documentation
-=============
-
-* **Installation Guide(s):**
-
- * N/A
-
-* **User Guide(s):**
-
- * :doc:`User Guide </user-guide/genius-user-guide>`
-
-* **Developer Guide(s):**
-
- * :doc:`Developer Guide </submodules/genius/docs/index>`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * No
-
-* Other security issues?
-
- * N/A
-
-Quality Assurance
-=================
-
-* `Sonar Report <https://sonar.opendaylight.org/overview?id=64114>`_
-
-* Link to CSIT Jobs
-
- * `CSIT Job basic <https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-oxygen//>`_
-
- * `CSIT Job clustering <https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-3node-upstream-all-oxygen//>`_
-
- * `Netvirt CSIT for Genius patches <https://jenkins.opendaylight.org/releng/job/genius-patch-test-netvirt-oxygen/>`_
-
- * `Netvirt Cluster CSIT for Genius patches <https://jenkins.opendaylight.org/releng/job/genius-patch-test-cluster-netvirt-oxygen/>`_
-
- .. note:: Genius is used extensively in NetVirt, so NetVirt's CSIT also
- provides confidence in genius.
-
-* Other manual testing and QA information
-
- * N/A
-
-* Testing methodology. How extensive was it? What should be expected to work?
- What hasn't been tested as much?
-
- * `Running Genius CSIT in Dev Environmrnt <http://docs.opendaylight.org/en/latest/submodules/genius/docs/genius-csit-howto.html/>`_
- * `Genius test plans <http://docs.opendaylight.org/en/latest/submodules/genius/docs/testplans/index.html>`_
-
- .. note:: fcaps_framework and fcaps_application features hasn't been tested
- much.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- * No. OpenDaylight doesn't support migration natively for applications that
- use datastore.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- * Functionality is fully backwards compatible.
-
-* Any API changes?
-
- * New APIs added for `itm-scale-improvements </submodules/genius/docs/specs/itm-scale-improvements>` feature
-
-* Any configuration changes?
-
- * No
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
- * `Fixed BUGS <https://jira.opendaylight.org/browse/GENIUS-112?jql=project%20in%20(genius)%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Resolved%2C%20Verified)%20AND%20created%20%3E%3D%202017-08-14%20AND%20created%20%3C%3D%202018-03-07>`_
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- * None
-
-* `Open Bugs <https://jira.opendaylight.org/browse/GENIUS>`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this
- release
-
- * N/A
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- * N/A
-
-Release Mechanics
-=================
-
-* `Release plan <https://wiki.opendaylight.org/view/Genius:Oxygen_Release_Plan>`_
-
-* Describe any major shifts in release schedule from the release plan
-
- * N/A
+++ /dev/null
-==========
-Infrautils
-==========
-
-Major Features
-==============
-
-odl-infrautils-all
-------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/odl-infrautils-all/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature exposes all infrautils framework features
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** covered by Netvirt and Genius CSITs
- * https://jenkins.opendaylight.org/releng/view/netvirt/job/netvirt-csit-1node-openstack-queens-upstream-stateful-oxygen/
- * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-gate-all-oxygen/
-
-.. note that this is experimental until the system test waiver is granted
-.. on this thread:
-.. https://lists.opendaylight.org/pipermail/infrautils-dev/2017-May/000322.html
-
-odl-infrautils-jobcoordinator
------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/odl-infrautils-jobcoordinator/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature exposes the jobcoordinator framework which is heavily used in genius and netvirt.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** covered by Netvirt and Genius CSITs
-
-odl-infrautils-metrics
-----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/odl-infrautils-metrics/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature exposes the new infrautils.metrics API with labels and first implementation based on Dropwizard incl. thread watcher
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** covered by Netvirt and Genius CSITs
-
-odl-infrautils-ready
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/odl-infrautils-ready/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature exposes the system readiness framework
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** covered by Netvirt and Genius CSITs
-
-odl-infrautils-caches
----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/odl-infrautils-caches/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature exposes new infrautils.caches API, CLI commands for monitoring, and first implementation based on Guava
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** covered by Netvirt and Genius CSITs
-
-odl-infrautils-diagstatus
--------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/odl-infrautils-diagstatus/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature exposes the status and diagnostics framework
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** covered by Netvirt and Genius CSITs
-
-
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :doc:`User Guide </submodules/infrautils/docs/specs/index>`
-
-* **Developer Guide(s):**
-
- * :doc:`Developer Guide </submodules/infrautils/docs/index>`
-
-Security Considerations
-=======================
-
-* JMX RMI Registry opens on port listed at https://wiki.opendaylight.org/view/Ports
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.infrautils%3Ainfrautils>`_
-* Project infrautils provides low-level technical framework utilities
- and therefore no CSIT automated system testing is available. However
- the same gets covered by the CSIT of users of infrautils (eg : Genius, Netvirt)
-
-Migration
----------
-
-* No additional migration steps needed
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- * Functionality is fully backwards compatible.
-
-* Any API changes?
-
- * New APIs added for diagstatus
- * New APIs added for metrics
- * New APIs added for caches
-
-* Any configuration changes?
-
- * No
-
-Bugs Fixed
-----------
-
-* `List of bugs fixed since the previous release: <https://jira.opendaylight.org/browse/INFRAUTILS-29?jql=project%20%3D%20INFRAUTILS%20AND%20created%20%3E%3D%202017-10-07%20AND%20created%20%3C%3D%202018-03-08>`_
-
-Known Issues
-------------
-
-* There are no currently known issues
-
-End-of-life
-===========
-
-* This section is N/A
-
-Standards
-=========
-
-* This section is N/A
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/InfraUtils:Oxygen:Release_Plan>`_
+++ /dev/null
-========
-JSON-RPC
-========
-
-Major Features
-==============
-
-jsonrpc
-------------
-
-This is the first official release of the JSON RPC extension. It
-provides JSON RPC client support as well as support for one
-transport - Zero MQ.
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`jsonrpc-user-guide.rst`
-
-* **Developer Guide(s):**
-
- * :ref:`jsonrpc`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * Configurable Zero MQ listener endpoint - by default disabled.
-
-* Other security issues?
-
- * None.
-
-Quality Assurance
-=================
-
-* JSON RPC is being tested extensively as a part of ongoing work
- on integrating it with OpenSwitch and other projects.
-* Unit tests
-
-Migration
----------
-
-* Simply install and restart daemons.
-
-Compatibility
--------------
-
-* N/A
-
-Bugs Fixed
-----------
-
-* N/A - Initial release
-
-
-Known Issues
-------------
-
-* None
-
-End-of-life
-===========
-
-* None
-
-Standards
-=========
-
-* `Yang Modelled JSON RPC draft <https://tools.ietf.org/html/draft-yang-json-rpc-02>`_ (reference implementation)
+++ /dev/null
-========
-L2Switch
-========
-
-odl-l2switch-switch
--------------------
-* **Feature Description:** Provides a basic L2 Switch abstraction over multiple switches using OpenFlow
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-all-oxygen/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-merge-oxygen/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-sonar/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-validate-autorelease-oxygen/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-maven-clm-oxygen/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-periodic-host-scalability-daily-only-oxygen/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-scalability-all-oxygen/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-all-oxygen/
- * https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-distribution-check-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`l2switch-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`l2switch-dev-guide`
-
-Security Considerations
-=======================
-
-* `CVE-2015-1610 <https://www.cvedetails.com/cve/CVE-2015-1610/>`_: Hosttracker data may be manipulated via MAC address spoofing.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=org.opendaylight.l2switch%3Al2switch>`_
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/l2switch/>`_
-* The tests are using the OpenDaylight CSIT infrastructure.
-
- * How extensive was it? *Covers functionality and basic scalability*
- * What should be expected to work? *Basic functions: packet handling, address tracking, host discovery, mininet pingall success (with flood mode enabled)*
- * What has not be tested as much? *Extensive scalability testing, clustering*
-
-Migration
----------
-
-Data should be migratable from Nitrogen to Oxygen.
-
-Compatibility
--------------
-
-This release is compatible with the previous release.
-
-Bugs Fixed
-----------
-
-No bug is fixed in this release.
-
-Known Issues
-------------
-
-* `L2SWITCH-81 <https://jira.opendaylight.org/browse/L2SWITCH-81>`_: l2switch does not work well when mininet is stopped/started with no delay.
-
-End-of-life
-===========
-No Changes
-
-Standards
-=========
-
-None.
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/L2_Switch:Oxygen_Release_Plan>`_
-* No major changes.
+++ /dev/null
-=================
-LISP Flow Mapping
-=================
-
-Major Features
-==============
-
-odl-lispflowmapping-msmr
-------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob;f=features/odl-lispflowmapping-msmr/pom.xml
-* **Feature Description:** This is the core feature that provides the Mapping Services and includes the LISP southbound plugin feature as well.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/lispflowmapping/job/lispflowmapping-csit-1node-msmr-all-oxygen/
-
-odl-lispflowmapping-neutron
----------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob;f=features/odl-lispflowmapping-neutron/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature provides Neutron integration.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-
-odl-lispflowmapping-ui
-----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=lispflowmapping.git;a=blob;f=features/odl-lispflowmapping-ui/pom.xml;hb=stable/oxygen
-* **Feature Description:** This feature provides a GUI to access the Mapping Service data.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-
-Documentation
-=============
-
-* **User Guide(s):**
- :ref:`lispflowmapping-user-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-* Yes, the southbound plugin
-
- * If so, how are they secure?
- * LISP southbound plugin follows LISP `RFC6833 <https://tools.ietf.org/html/rfc6833>`_ security guidelines.
-
- * What port numbers do they use?
- * Port used: 4342
-
-* Other security issues?
- * None
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.lispflowmapping%3Alispflowmapping-all>`_ (59.5%)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/lispflowmapping/>`_
-* All modules have been unit tested. Integration tests have been performed for all major features. System tests have been performed on most major features.
-* Registering and retrieval of basic mappings have been tested more thoroughly. More complicated mapping policies have gone through less testing.
-
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- * LISP Flow Mapping service will auto-populate the datastructures from existing MD-SAL data upon service start if the data has already been migrated separately. No automated way for transfering the data is provided in this release.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- * Yes
-
-* Any API changes?
-
- * No
-
-* Any configuration changes?
-
- * No
-
-Bugs Fixed
-----------
-
-* `LISPMAP-151 <https://jira.opendaylight.org/browse/LISPMAP-151>`_ Subscribers from both Northbound and Southbound origin are stored in SimpleMapCache
-* `LISPMAP-152 <https://jira.opendaylight.org/browse/LISPMAP-152>`_ Integration tests: multi-site doesn't send SMR-invoked Map-Request on SMR
-* `LISPMAP-155 <https://jira.opendaylight.org/browse/LISPMAP-155>`_ SMR scheduler task tracking unreliable
-* `LISPMAP-163 <https://jira.opendaylight.org/browse/LISPMAP-163>`_ Merging of negative prefixes is incorrect
-* `LISPMAP-164 <https://jira.opendaylight.org/browse/LISPMAP-164>`_ Negative mapping in SB masking overlapping more specific positive added later to NB
-* `LISPMAP-165 <https://jira.opendaylight.org/browse/LISPMAP-165>`_ Adding a less specific NB mapping when an included more specific SB exists leads to SB taking preference
-* `LISPMAP-166 <https://jira.opendaylight.org/browse/LISPMAP-166>`_ Integration tests receiveMap(Request|Notify) don't check for packet type before deserializing
-* `LISPMAP-168 <https://jira.opendaylight.org/browse/LISPMAP-168>`_ When lazy removing expired mappings, the mapping system doesn't check for less specifics
-* `LISPMAP-169 <https://jira.opendaylight.org/browse/LISPMAP-169>`_ MapServer should not send SMR for when source EID was AFI=0 (No Address)
-* `LISPMAP-171 <https://jira.opendaylight.org/browse/LISPMAP-171>`_ Karaf CLI commands should trigger expired mapping removal
-* `LISPMAP-173 <https://jira.opendaylight.org/browse/LISPMAP-173>`_ NPE in MappingSystem#removeMapping()
-
-
-Known Issues
-------------
-
-* Clustering is still an experimental feature and may have some issues particularly related to operational datastore consistency.
-
-* `Link to Open Bugs <https://jira.opendaylight.org/projects/LISPMAP/issues/>`_
-
-End-of-life
-===========
-
-* None
-
-Standards
-=========
-
-* The LISP implementation module and southbound plugin conforms to the IETF `RFC6830 <https://tools.ietf.org/html/rfc6830>`_ and `RFC6833 <https://tools.ietf.org/html/rfc6833>`_ , with the following exceptions:
-
- - In Map-Request message, M bit(Map-Reply Record exist in the MapRequest) is processed but any mapping data at the bottom of a Map-Request are discarded.
- - LISP LCAFs are limited to only up to one level of recursion, as described in the IETF `LISP YANG draft <https://tools.ietf.org/html/draft-ietf-lisp-yang-07>`_.
- - No standards exist for the LISP Mapping System northbound API as of this date.
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/OpenDaylight_Lisp_Flow_Mapping:Oxygen_Release_Plan>`_
-
- * No major shifts from the release plan.
+++ /dev/null
-======
-MD-SAL
-======
-
-Major Features
-==============
-
-Oxygen release of MD-SAL has focused on incremental improvements in existing
-functionality. Major newsworthy items are:
-* Improved length constraint checks in generated code
-* Reworked Cluster Singleton service
-* DOMSchemaService has received fixes which were delivered only to controller
-* Binding V2 implementation has gotten faster, smaller and more feature-complete
-* DOMReadWriteTransaction has been introduced to allow migration from controller
-* Binding data tree changes adaptation has been corrected
-* Potential livelock in DOMForwardedWriteTransaction has been fixed
-* Runtime code footprint of Binding V1 has been reduced
-
-odl-mdsal-binding
------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=mdsal.git;a=blob;f=common/features/odl-mdsal-binding/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** MDSAL Binding layer, representing mapping of YANG
- modeled data to respective Java Objects
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/mdsal/job/mdsal-csit-1node-periodic-bindingv1-only-oxygen/
-
-odl-mdsal-binding2
-------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=mdsal.git;a=blob;f=common/features/odl-mdsal-binding2/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** MDSAL Binding v2 layer, representing mapping of YANG
- modeled data to respective Java Objects
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-
-odl-mdsal-dom
--------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=mdsal.git;a=blob;f=common/features/odl-mdsal-dom/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** MDSAL DOM layer
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-
-Documentation
-=============
-
-* **Developer Guide(s):**
-
- * :ref:`MDSAL Developer guide <mdsal_dev_guide>`
-
- * `MDSAL Binding v2 guide <https://github.com/opendaylight/mdsal/blob/stable/nitrogen/docs/src/main/asciidoc/developer/analysis/binding-v2.adoc>`_
-
-Security Considerations
-=======================
-
-* MDSAL libraries are designed to be embedded and not to be a stand-alone
- application so security concerns need to be addressed by the application
- using this library.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.mdsal%3Amdsal-agreggator>`_
- (63.2% line, 53% branch, 60.4% overall coverage)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/mdsal/job/mdsal-csit-1node-periodic-bindingv1-only-oxygen/>`_
-
-Migration
----------
-
-* no additional steps needed for migration
-
-Compatibility
--------------
-
-* Release is compatible with the previous one
-* No configuration changes
-
-Bugs Fixed
-----------
-
-* `Link of fixed bugs <https://jira.opendaylight.org/issues/?jql=project%20%3D%20MDSAL%20and%20resolution%20%3D%20Done%20and%20fixVersion%20%3D%20%22Oxygen%22%20>`_
-
-Known Issues
-------------
-
-* None
-
-End-of-life
-===========
-
-* Users are advised that any API element marked as @deprecated may be removed
- in the next release. Users are advised to follow JavaDoc pointers and migrate
- to replacement APIs.
-
-Standards
-=========
-
-* relies on processing according to
- `RFC 6020 <https://tools.ietf.org/html/rfc6020>`_ and
- `RFC 7950 <https://tools.ietf.org/html/rfc7950>`_.
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/MD-SAL:Oxygen:Release_Plan>`_
+++ /dev/null
-======================
-NEtwork MOdeling(NEMO)
-======================
-
-Major Features
-==============
-
-
-* odl nemo rest provides an abstracted intent model whose target is to enable network users/applications to describe their intent in an intuitive way without caring about the underlying physical network.
-* nemo engine is the core module of NEMO project, which releases the mapping from intent to physical network. It includes two import process: intent-virtual network(VN) and virtual network-physical network(PN).
-* openflow renderer is a sourthbound render to translate the mapping result of VN-PN to flow table in devices supporting for openflow protocol.
-* cli render is also a sourthbound render to translate the mapping result of VN-PNinto forwarding table in devices supporting for traditional protocol.
-* nemo engine ui is reponsible for showing the status of physical network, intent, generated virtual network and mapping result of VN-PN, which facilitate users to understand better the intent handling process if they want to.
-
-NEMO Engine UI
---------------
-
-* **Feature Name:** odl-nemo-engine-ui
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=nemo.git;a=blob;f=nemo-features/odl-nemo-engine-ui/pom.xml;
-* **Feature Description:** DSL based for the abstraction of network models and conclusion of operation patterns.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/nemo
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`nemo-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`nemo-dev-guide`
-
-Security Considerations
-=======================
-
-* There are no security issues found.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=53347>`_ 42.8%
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/nemo>`_
-* `Manual Tests <https://wiki.opendaylight.org/view/NEMO:System_Test>`_
-* External System Test is done manually, since the sandbox environment could not satisfy NEMO's requirements.
-
-Migration
----------
-
-* Nothing beyond general OpenDaylight migration requirements.
-
-Compatibility
--------------
-
-* Nothing beyond general OpenDaylight compatibility constraints.
-
-Bugs Fixed
-----------
-
-* `NEMO Bug List <https://jira.opendaylight.org/projects/NEMO>`_
-
-Known Issues
-------------
-
-
-* For using openflow-renderer, requiring special switch to construct physical network. The install guide is in https://github.com/zhangmroy?tab=repositories. Other virtual switch, such as, ovs, will be support in future OpenDaylight version.
-* For using cli-renderer, the physical network should be constructed with Huawei's device: NE40E. More devices will be considered in the future OpenDaylight versions.
-
-End-of-life
-===========
-
-* Nothing deprecated, EOL.
-
-Standards
-=========
-
-* N/A
-
-Release Mechanics
-=================
-
-* `NEMO Release Plan <https://wiki.opendaylight.org/view/NEMO:Release_Plan>`_
-* Project was on schedule
+++ /dev/null
-=======
-NETCONF
-=======
-
-Major Features
-==============
-
-For each top-level feature, identify the name, url, description, etc.
-User-facing features are used directly by end users.
-
-odl-netconf-topology
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/netconf-connector/odl-netconf-topology/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** NETCONF southbound plugin single-node, configuration through mdsal
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-1node-userfeatures-all-oxygen/
-
-odl-netconf-clustered-topology
-------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/netconf-connector/odl-netconf-clustered-topology/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** NETCONF southbound plugin clustered, configuration through mdsal
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-3node-clustering-all-oxygen/
-
-odl-netconf-console
--------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/netconf-connector/odl-netconf-console/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** NETCONF southbound configuration with karaf cli
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-
-odl-netconf-mdsal
------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/netconf/odl-netconf-mdsal/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** NETCONF server for mdsal
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-1node-userfeatures-all-oxygen/
-
-odl-restconf
-------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/restconf/odl-restconf/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** Restconf
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** Tested by any suite that uses Restconf
-
-odl-mdsal-apidocs
------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/restconf/odl-mdsal-apidocs/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** MDSal - apidocs
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-
-odl-yanglib
------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/yanglib/odl-yanglib/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** Yanglib server
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-
-odl-netconf-callhome-ssh
-------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=netconf.git;a=blob;f=features/netconf-connector/odl-netconf-callhome-ssh/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** Netconf call home
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/netconf/job/netconf-csit-1node-callhome-all-oxygen/
-
-
-Documentation
-=============
-
-Please provide the URL to each document at docs.opendaylight.org. If the
-document is under review, provide a link to the change in Gerrit.
-
-* **User Guide(s):**
-
- * :ref:`netconf-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`netconf-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- Yes, we have md-sal and css netconf servers. Also server for netconf call-home.
-
- * If so, how are they secure?
-
- NETCONF over SSH
-
- * What port numbers do they use?
-
- Please see https://wiki.opendaylight.org/view/Ports. Netconf call-home uses TCP port 6666
-
-* Other security issues?
-
- None that we are aware of
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.netconf%3Anetconf-parent>`_ Test coverage percent: 60.7%
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/netconf/>`_
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- Yes. No additional steps required.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- Yes
-
-* Any API changes?
-
- No
-
-* Any configuration changes?
-
- No
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
- https://jira.opendaylight.org/browse/NETCONF-479?jql=project%20%3D%20NETCONF%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Resolved%2C%20Verified)%20AND%20fixVersion%20in%20(Oxygen%2C%20Nitrogen-SR1)%20ORDER%20BY%20created%20DESC
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- None
-
-* `Link to Open Bugs <https://jira.opendaylight.org/browse/NETCONF-528?jql=project%20%3D%20NETCONF%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Confirmed)%20ORDER%20BY%20created%20DESC>`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this
- release
-
- None of the features/APIs are EOLed, deprecated or removed.
-
-Standards
-=========
-
-* `RFC 6241 <https://tools.ietf.org/html/rfc6241>`_ - Network Configuration Protocol (NETCONF)
-* `RFC 6470 <https://tools.ietf.org/html/rfc6470>`_ - Base Notifications partly supported, netconf-config-change unsupported
-* `draft-ietf-yang-library-06 <https://tools.ietf.org/html/draft-ietf-netconf-yang-library-06>`_
-* `draft-bierman-netconf-restconf-04 <https://tools.ietf.org/html/draft-bierman-netconf-restconf-04>`_
-* `RFC 8040 <https://tools.ietf.org/html/rfc8040>`_ - RESTCONF protocol
-
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/Simultaneous_Release:Oxygen_Release_Plan>`_
-* Describe any major shifts in release schedule from the release plan
-
- No shifts
+++ /dev/null
-=======
-NetVirt
-=======
-
-Major Features
-==============
-
-Feature Name
-------------
-
-* **Feature Name:** odl-netvirt-openstack
-* **Feature URL:** `odl-netvirt-openstack <https://git.opendaylight.org/gerrit/gitweb?p=netvirt.git;a=blob;f=vpnservice/features/odl-netvirt-openstack/pom.xml;hb=HEAD>`_
-* **Feature Description:** NetVirt is a network virtualization solution that includes the following components as well
- as others: Open vSwitch based virtualization for software switches, Hardware VTEP for hardware switches,
- Service Function Chaining support within a virtualized environment, support for OVS and DPDK-accelerated
- OVS data paths, L3VPN (BGPVPN), EVPN, ELAN, distributed L2 and L3, NAT and Floating IPs, IPv6, Security Groups,
- MAC and IP learning.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** `NetVirt CSIT <https://jenkins.opendaylight.org/releng/job/netvirt-csit-1node-openstack-queens-upstream-stateful-oxygen/>`_
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :doc:`../../submodules/netvirt/docs/user-guide/index`
- * :doc:`../../submodules/netvirt/docs/openstack-guide/index`
-
-* **Developer Guide(s):**
-
- * :doc:`../../submodules/netvirt/docs/developer-guide/index`
-
-* **Contributor Guide(s):**
-
- * :doc:`../../submodules/netvirt/docs/contributor-guide/index`
-
-Security Considerations
-=======================
-
-No known issues.
-
-Quality Assurance
-=================
-
-* `Sonar Report <https://sonar.opendaylight.org/overview?id=64219>`_
-* `All CSIT Jobs <https://jenkins.opendaylight.org/releng/view/netvirt-csit>`_
-* `Main test job <https://jenkins.opendaylight.org/releng/job/netvirt-csit-1node-openstack-queens-upstream-stateful-oxygen/>`_
-
-Migration
----------
-
-Nothing beyond general migration requirements.
-
-Compatibility
--------------
-
-Nothing beyond general compatibility requirements.
-
-Bugs Fixed
-----------
-
-* `Closed Bugs <https://jira.opendaylight.org/issues/?jql=project%20%3D%20NETVIRT%20AND%20resolution%20%3D%20Done%20AND%20affectedVersion%20%3D%20Oxygen%20>`_
-
-Known Issues
-------------
-
-* `Open Bugs <https://jira.opendaylight.org/issues/?jql=project%20%3D%20NETVIRT%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%20Oxygen%20>`_
-
-End-of-life
-===========
-
-N/A
-
-Standards
-=========
-
-N/A
-
-Release Mechanics
-=================
-
-* `Release Plan <https://wiki.opendaylight.org/view/NetVirt:Oxygen:Release_Plan>`_
-* Project was on schedule
+++ /dev/null
-==================
-Neutron Northbound
-==================
-
-Major Features
-==============
-
-* Tap-as-a-Service (TapAAS) for port mirroring
-* Minimum bandwidth QoS rule
-* Various code clean up(checkstyle, findbugs, and pom cleanup)
-
-odl-neutron-service
--------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=features/production/odl-neutron-service/pom.xml;hb=refs/heads/stable/nitrogen
-* **Feature Description:** This is a top level feature to load Neutron
- northbound functionality.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** no CSIT tests as test weiver had been requested.
- OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
-
-odl-neutron-northbound-api
---------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=features/production/odl-neutron-northbound-api/pom.xml;hhb=refs/heads/stable/nitrogen
-* **Feature Description:** This feature provides REST API for
- OpenStack Neutron
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** no CSIT tests as test weiver had been requested.
- OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
-
-
-odl-neutron-spi
----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=features/production/odl-neutron-spi/pom.xml;hb=stable/nitrogen
-* **Feature Description:** SPI for Neutron northbound feature
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** no CSIT tests as test weiver had been requested.
- OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
-
-odl-neutron-transcriber
------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=features/production/odl-neutron-transcriber/pom.xml;hb=stable/nitrogen
-* **Feature Description:** Data converter from/to REST API to/from
- MD-SAL YANG model
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** no CSIT tests as test weiver had been requested.
- OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
-
-odl-neutron-logger
-------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=features/production/odl-neutron-logger/pom.xml;hb=stable/nitrogen
-* **Feature Description:** Logger on activity on Neutron YANG models
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** no CSIT tests as test weiver had been requested.
- OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
-
-odl-neutron-hostconfig-ovs
---------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=features/production/odl-neutron-hostconfig-ovs/pom.xml;hb=stable/nitrogen
-* **Feature Description:** Helper library to support hostconfig for
- OpenStack service provider with Open vSwitch
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** no CSIT tests as test weiver had been requested.
- OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
-
-odl-neutron-hostconfig-vpp
---------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=neutron.git;a=blob;f=features/production/odl-neutron-hostconfig-vpp/pom.xml;hb=stable/nitrogen
-* **Feature Description:** Helper library to support hostconfig for
- OpenStack service provider with VPP
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** no CSIT tests as test weiver had been requested.
- OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
-
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`neutron-service-user-guide` is a guide for cloud admin who
- deploys OpenStack with OpenDaylight.
-
-* **Developer Guide(s):**
-
- * :ref:`neutron-northbound-developer-guide` is a guide for those who
- develops new Neutron Northbound API which OpenStack Neutron talks to.
- * :ref:`neutron-service-developer-guide` is a guide for those who
- develops new OpenStack Service Provider like netvirt,
- group-based-policy.
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- Yes. REST API for OpenStack Neutron.
-
- * If so, how are they secure?
- It's authenticated by AAA.
- * What port numbers do they use?
- 8080 and 8181 by default. 8087 is also used by networking-odl/devstack.
-
-* Other security issues?
-
- None.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=org.opendaylight.neutron%3Aproject-neutron>`_ (55.3%)
-* Link to CSIT Jobs N/A
-* Other manual testing and QA information
-
- * OpenStack CI results can be found from
- https://review.openstack.org/#/q/project:openstack/networking-odl
- * failure rate of OpenStack CI
- http://grafana.openstack.org/dashboard/db/networking-odl-failure-rate
- * Other OpenDaylight projects which provides OpenStack Service
- (e.g. netvirt, group-based-policy and vtn etc..) have their own system
- tests which also exercise Neutron Norhtbound. Which give coverage.
-
-
-* Testing methodology. How extensive was it? What should be expected
- to work? What hasn't been tested as much?
-
- * Unit test: coverage 53.4%
- * Integration test:
- * OpenStack CI
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- No as incompatble change was introduced.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- Yes.
-
-* Any API changes?
-
- New API (TapAAS, minimum bandwidth qos rule) were introduced. Not change
- to the existing API.
-
-* Any configuration changes?
-
- No.
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
- * `Link to Bugs fixed
- <https://jira.opendaylight.org/issues/?jql=project%20%3D%20NEUTRON%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20%3D%20Oxygen>`_
-
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- None
-
-* `Link to Open Bugs
- <https://jira.opendaylight.org/projects/NEUTRON/>`_
-
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this release
-
- N/A
-
-Standards
-=========
-
-* List of standrads implemented and to what extent
-
- `OpenStack Neutron API
- <https://developer.openstack.org/api-ref/networking/v2/>`_
- ODL Neutron Northbound REST API is based on OpenStack Neutron API
- and OpenStack Neutron implementation. So the two REST APIs are
- similar inherently, but different if necessary for technical
- reason. The goal of ODL Neutron Northbound project is to help
- OpenStack ODL driver for OpenStack Neutron (networking-odl) and ODL
- OpenStack Service Provider(netvirt, group-based-policy, and vtn
- etc...). Not re-implement OpenStack Neutron API.
-
-
-Release Mechanics
-=================
-
-* `Link to release plan
- <https://wiki.opendaylight.org/view/NeutronNorthbound:Oxygen_Release_Plan>`_
-* Describe any major shifts in release schedule from the release plan
-
- * Postponed YANG model change to drop tenant-id, make status
- operational to Fluorine cycle
+++ /dev/null
-==========
-ODL Parent
-==========
-
-Major Features
-==============
-
-There are no user-visible features.
-
-Documentation
-=============
-
-* **Developer Guide(s):**
-
- * :ref:`odl-parent-developer-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- No.
-
-* Other security issues?
-
- No.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=23179>`_ (6.4% coverage)
-* There are no CSIT jobs, ODL Parent has a system test waiver
-* ODL Parent is tested by all builds, and manually tested by running the basic
- Karaf container and verifying the scripts we modify (``client`` in
- particular).
-* We verify the following:
-
- * ``start`` starts the Karaf container.
- (in a working state, capable of installing features)
- * ``client`` can connect to a running Karaf container.
- * ``stop`` stops a running Karaf container.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- Yes. Projects may encounter issues upgrading to Karaf 4.1, which is used in
- this release; however there aren’t generic upgrade instructions.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- No.
-
-* Any API changes?
-
- The ``odl-triemap-0.2`` feature wrapping
- ``com.github.romix:java-concurrent-hash-trie-map`` was rendered obsolete by
- YANG Tools' implementation and has been removed.
-
- The following third-party dependencies have been removed from dependency
- management:
-
- * Chameleon MBeans
- * Eclipse Link
- * Equinox HTTP service bridge
- * ``equinoxSDK381`` artifacts
- * Coda Hale Metrics, which are mostly unused and should eventually be wrapped
- by InfraUtils
- * ``com.google.code.findbugs:jsr305`` (which *must not* be used; this is
- enforced — ``annotations`` should be used instead)
- * Felix File Install and Web Console
- * Gemini Web
- * Orbit
- * ``org.mockito:mockito-all`` (which *must not* be used; this is enforced —
- ``mockito-core`` should be used instead)
- * Spring Framework
- * ``txw2``
- * Xerces
- * ``xml-apis``
-
-* Any configuration changes?
-
- No. ODL Parent has no user-visible configuration.
-
-Bugs Fixed
-----------
-
-* `66: Consolidate web services to bind to a single port <https://jira.opendaylight.org/browse/ODLPARENT-66>`_
-* `86: Milestone: Upgrade karaf to 4.1.2 or later <https://jira.opendaylight.org/browse/ODLPARENT-86>`_
-* `121: Upgrade maven-javadoc-plugin to 3.0.0 <https://jira.opendaylight.org/browse/ODLPARENT-121>`_
-* `132: odlparent 2.0.5 depends on servlet-api/3.0.1, whereas Karaf 4 depends on /3.1.0 <https://jira.opendaylight.org/browse/ODLPARENT-132>`_
-* `133: Our base distribution doesn’t include webconsole <https://jira.opendaylight.org/browse/ODLPARENT-133>`_
-* `135: Karaf feature:installation “deadlock” <https://jira.opendaylight.org/browse/ODLPARENT-135>`_
-
-Known Issues
-------------
-
-* `Link to Open Bugs <https://jira.opendaylight.org/browse/ODLPARENT>`_
-
-End-of-life
-===========
-
-* N/A.
-
-Standards
-=========
-
-* N/A.
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/ODL_Parent:Oxygen_Release_Plan>`_
+++ /dev/null
-=========
-OF-CONFIG
-=========
-
-Major Features
-==============
-
-odl-of-config-all
------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=of-config.git;a=blob;f=features/features-of-config/src/main/features/features.xml;h=86615e2f22ebc8f21b403185d3a600aa2a463588;hb=HEAD
-* **Feature Description:** This is a top level wrapper feature which includes all the sub features of-config offers.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/of-config/job/of-config-csit-1node-basic-all-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`ofconfig-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`ofconfig-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * No. This project indirectly uses the NETCONF project to connect to devices.
-
-* Other security issues?
-
- * Security issues are provided in the RESTCONF and NETCONF projects.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=org.opendaylight.of-config%3Aofconf>`_ (71.4% code coverage)
-* Other manual testing and QA information
-* Testing methodology. How extensive was it? What should be expected to work?
- What has not been tested as much?
-* External System Test is almost done manually. The test has coverd all external APIs of OF-CONFIG and all supplementary options based on OF-CONFIG 1.2.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
-Yes, there are no additional steps for migration.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release? Yes.
-* Any API changes? No.
-* Any configuration changes? No.
-
-Bugs Fixed
-----------
-
-None.
-
-Known Issues
-------------
-
-* No known issues.
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this
- release
-
- N/A
-
-Standards
-=========
-
-* List of standrads implemented and to what extent
-* `OF-CONFIG 1.2 <https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow-config/of-config-1.2.pdf>`_
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/OF-CONFIG:Oxygen:Release_Plan>`_
-* Describe any major shifts in release schedule from the release plan
-
- N/A
+++ /dev/null
-======================
-OpenFlowPlugin Project
-======================
-
-Major Features
-==============
-
-odl-openflowjava-protocol
--------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=openflowjava/features-openflowjava-aggregator/odl-openflowjava-protocol/pom.xml
-* **Feature Description:** OpenFlow protocol implementation
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-app-config-pusher
-------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-app-config-pusher/pom.xml
-* **Feature Description:** Pushes node configuration changes to OpenFlow device
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-app-forwardingrules-manager
-----------------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-app-forwardingrules-manager/pom.xml
-* **Feature Description:** Sends changes in config datastore to OpenFlow device incrementally. forwardingrules-manager can be replaced with forwardingrules-sync and vice versa.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-app-forwardingrules-sync
--------------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-app-forwardingrules-sync/pom.xml
-* **Feature Description:** Sends changes in config datastore to OpenFlow devices taking previous state in account and doing diffs between previous and new state. forwardingrules-sync can be replaced with forwardingrules-manager and vice versa.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/job/openflowplugin-csit-1node-flow-services-all-oxygen/
-
-odl-openflowplugin-app-table-miss-enforcer
-------------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-app-table-miss-enforcer/pom.xml
-* **Feature Description:** Sends table miss flows to OpenFlow device when it connects
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-app-topology
--------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-app-topology/pom.xml
-* **Feature Description:** Discovers topology of connected OpenFlow devices
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-nxm-extensions
----------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=extension/features-extension-aggregator/odl-openflowplugin-nxm-extensions/pom.xml
-* **Feature Description:** Support for OpenFlow Nicira Extensions
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/netvirt/job/netvirt-csit-1node-openstack-pike-gate-stateful-snat-conntrack-oxygen/
-
-
-odl-openflowplugin-onf-extensions
----------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=extension/features-extension-aggregator/odl-openflowplugin-onf-extensions/pom.xml
-* **Feature Description:** Support for Open Networking Foundation Extensions
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** No
-
-odl-openflowplugin-flow-services
---------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-flow-services/pom.xml
-* **Feature Description:** Wrapper feature for standard applications
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-flow-services-rest
--------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-flow-services-rest/pom.xml
-* **Feature Description:** Wrapper + REST interface
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-flow-services-ui
------------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-flow-services-ui/pom.xml
-* **Feature Description:** Wrapper + REST interface + UI
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-nsf-model
-----------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-nsf-model/pom.xml
-* **Feature Description:** OpenFlowPlugin YANG models
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-odl-openflowplugin-southbound
------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=openflowplugin.git;a=blob;f=features-aggregator/odl-openflowplugin-southbound/pom.xml
-* **Feature Description:** Southbound API implementation
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :doc:`../../user-guide/openflow-plugin-project-user-guide`
-
-* **Developer Guide(s):**
-
- * :doc:`../../developer-guide/openflow-plugin-project-developer-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF? Yes, OpenFlow devices
-* Other security issues?
-
- * `Insecure OpenFlowPlugin <--> OpenFlow device connections <https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:_TLS_Support>`_
- * Topology spoofing: non authenticated LLDP packets to detect links between switches which makes it vulnerable to a number of attacks, one of which is topology spoofing The problem is that all controllers we have tested set chassisSubtype value to the MAC address of the local port of the switch, which makes it easy for an adversary to spoof that switch since controllers use that MAC address as a unique identifier of the switch. By intercepting clear LLDP packets containing MAC addresses, a malicious switch can spoof other switches to falsify the controller’s topology graph.
- * DoS: an adversary switch could generate LLDP flood resulting in bringing down the openflow network
- * `DoS attack when the switch rejects to receive packets from the controller <https://wiki.opendaylight.org/view/Security_Advisories#.5BModerate.5D_CVE-2017-1000357_Denial_of_Service_attack_when_the_switch_rejects_to_receive_packets_from_the_controller>`_
-
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.openflowplugin%3Aopenflowplugin-aggregator>`_ (73.8)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/openflowplugin-oxygen/>`_
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- Yes, API's from Nitrogen release are supported in Oxygen release.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release? Yes
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
- https://jira.opendaylight.org/browse/OPNFLWPLUG-974?jql=project%20%3D%20OPNFLWPLUG%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Resolved%2C%20Verified)%20AND%20fixVersion%20in%20(Oxygen%2C%20Nitrogen%2C%20Nitrogen-SR1)%20ORDER%20BY%20created%20DESC
-
-Known Issues
-------------
-
-* List key known issues with workarounds: None
-* `Link to Open Bugs <https://jira.opendaylight.org/browse/OPNFLWPLUG-987?jql=project%20%3D%20OPNFLWPLUG%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Confirmed)%20ORDER%20BY%20created%20DESC>`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this release: None
-
-Standards
-=========
-
-OpenFlow versions:
-
-* `OpenFlow1.3.2 <https://www.openflow.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.2.pdf>`_
-* `OpenFlow1.0.0 <https://www.openflow.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf>`_
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Oxygen_Release_Plan>`_
+++ /dev/null
-======
-OpFlex
-======
-
-Major Features
-==============
-
-OpFlex Agent
-------------
-
-OpFlex Agent provides support for local enforcement of group-based
-policy model synced using the OpFlex protocol using an Open
-vSwitch-based bridge. Supported renderer currently works with Cisco
-ACI.
-
-libopflex
----------
-
-libopflex provides an implementation of the OpFlex protocol along with
-an in-memory managed object database for managing OpFlex data.
-
-genie
------
-
-Genie provides a modeling language and code generator for producing
-data models that work with libopflex. Genie also contains the
-group-based policy model that is used by the OpFlex Agent.
-
-
-Documentation
-=============
-
-Please provide the URL to each document at docs.opendaylight.org. If the
-document is under review, provide a link to the change in Gerrit.
-
-* **Installation Guide(s):**
-
- * :ref:`opflex-agent-ovs-install-guide`
-
-* **User Guide(s):**
-
- * :ref:`opflex-agent-ovs-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`opflex-libopflex-dev-guide`
- * :ref:`opflex-genie-dev-guide`
- * :ref:`opflex-agent-ovs-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * No.
-
-* Other security issues?
-
- * None.
-
-Quality Assurance
-=================
-
-* OpFlex projects are tested with extensive unit testing as well as
- Cisco-internal automated testing with ACI.
-* Unit tests run as part of `regular build <https://jenkins.opendaylight.org/releng/view/opflex/job/opflex-merge-oxygen/43/>`_
-
-Migration
----------
-
-* Simply install and restart daemons.
-
-Compatibility
--------------
-
-OpFlex GBP model and configuration files remain backward compatible.
-
-Bugs Fixed
-----------
-
-* Occasionally would hang when restarting from a configuration reload.
-* Fix a possible memory leak when sending packets through packet-out
-* Fix an occasional crash when reporting statistics for removed
- endpoints or policy
-* Other minor issues fixed.
-
-
-Known Issues
-------------
-
-* None
-
-End-of-life
-===========
-
-* None
-
-Standards
-=========
-
-* `OpFlex protocol <https://tools.ietf.org/html/draft-smith-opflex-03>`_ (reference implementation)
+++ /dev/null
-=============
-OVSDB Project
-=============
-
-Major Features
-==============
-
-odl-ovsdb-southbound-api
-------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=southbound/southbound-features/odl-ovsdb-southbound-api/pom.xml;h=7baad461a78e7dd311516ec03b7dbf7c9a0679aa;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature provides the YANG models for northbound users to configure the OVSDB device.
- These YANG models are designed based on the `OVSDB schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`_. This
- feature does not provide the implementation of YANG models. If user/developer prefer to write their own implementation
- they can use this feature to load the YANG models in the controller.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-upstream-southbound-all-oxygen/
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-upstream-clustering-only-oxygen/
-
-odl-ovsdb-southbound-impl
--------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=southbound/southbound-features/odl-ovsdb-southbound-impl/pom.xml;h=261a85eacef24c1985a11f60d018816b1f880b10;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature is the main feature of the OVSDB Southbound plugin. This plugin handle the OVS
- device that supports the `OVSDB schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`_ and uses the
- `OVSDB protocol <https://tools.ietf.org/html/rfc7047>`_. This feature provides the implementation of the defined YANG
- models. Developers developing the in-controller application and want to leverage OVSDB for device configuration can
- add dependency on this feature and it will load all the required modules.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-upstream-southbound-all-oxygen/
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-upstream-clustering-only-oxygen/
-
-odl-ovsdb-southbound-impl-rest
-------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=southbound/southbound-features/odl-ovsdb-southbound-impl-rest/pom.xml;h=6a14e3f90fceba595695d69cdab2571e1a306999;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature is the wrapper feature that installs the odl-ovsdb-southbound-api &
- odl-ovsdb-southbound-impl feature with other required features for restconf access to provide a functional OVSDB
- southbound plugin. Users, who want to develop application that manages the OVSDB supported devices but want to runs
- the application outside of the OpenDaylight controller must install this feature.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-upstream-southbound-all-oxygen/
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-upstream-clustering-only-oxygen/
-
-
-odl-ovsdb-hwvtepsouthbound-api
-------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=hwvtepsouthbound/hwvtepsouthbound-features/odl-ovsdb-hwvtepsouthbound-api/pom.xml;h=e08f4233a6025da2d84dc1d87b6fb220a187e070;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature provides the YANG models for northbound users to configure the device
- that supports OVSDB Hardware vTEP schema. These YANG models are designed based on the
- `OVSDB Hardware vTEP schema <http://openvswitch.org/docs/vtep.5.pdf>`_. This feature does not provide the
- implementation of YANG models. If user/developer prefer to write their own implementation of the defined YANG
- model, they can use this feature to install the YANG models in the controller.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** Minimal set of CSIT test is already in place. More work is in progress and will have better functional
- coverage in Oxygen release.
-
- * https://jenkins.opendaylight.org/releng/view/Patch-Test/job/ovsdb-patch-test-l2gw-oxygen/
-
-odl-ovsdb-hwvtepsouthbound
---------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=hwvtepsouthbound/hwvtepsouthbound-features/odl-ovsdb-hwvtepsouthbound/pom.xml;h=3bb0d9f0093d83d0a82b3b8edffc0acfc93ee93c;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature is the main feature of the OVSDB Hardware vTep Southbound plugin. This plugin
- handle the OVS device that supports the `OVSDB Hardware vTEP schema <http://openvswitch.org/docs/vtep.5.pdf>`_ and
- uses the `OVSDB protocol <https://tools.ietf.org/html/rfc7047>`_. This feature provides the implementation of the
- defined YANG models. Developers developing the in-controller application and want to leverage OVSDB Hardware vTEP
- plugin for device configuration can add dependency on this feature and it will load all the required modules.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** Minimal set of CSIT test is already in place. More work is in progress and will have better functional
- coverage in Oxygen release.
-
- * https://jenkins.opendaylight.org/releng/view/Patch-Test/job/ovsdb-patch-test-l2gw-oxygen/
-
-odl-ovsdb-hwvtepsouthbound-rest
--------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=hwvtepsouthbound/hwvtepsouthbound-features/odl-ovsdb-hwvtepsouthbound-rest/pom.xml;h=8691103618cbe430994657016229b23c9b372d9d;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature is the wrapper feature that installs the odl-ovsdb-hwvtepsouthbound-api &
- odl-ovsdb-hwvtepsouthbound feature with other required features for restconf access to provide a functional OVSDB
- Hardware vTEP plugin. Users, who want to develop application that manages the hardware vTEP supported devices but want
- to runs the application outside of the OpenDaylight controller must install this feature.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** Minimal set of CSIT test is already in place. More work is in progress and will have better functional
- coverage in Oxygen release.
-
- * https://jenkins.opendaylight.org/releng/view/Patch-Test/job/ovsdb-patch-test-l2gw-oxygen/
-
-odl-ovsdb-library
------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=ovsdb.git;a=blob;f=library/features/odl-ovsdb-library/pom.xml;h=58002499237ac290071a89ca5e0b9c9297974400;hb=refs/heads/stable/oxygen
-* **Feature Description:** Encode/decoder library for OVSDB and Hardware vTEP schema.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:**
-
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-1node-upstream-southbound-all-oxygen/
- * https://jenkins.opendaylight.org/releng/view/ovsdb/job/ovsdb-csit-3node-upstream-clustering-only-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :doc:`OVSDB User Guide <../../user-guide/ovsdb-user-guide>`
-
-* **Developer Guide(s):**
-
- * :doc:`OVSDB Developer Guide <../../developer-guide/ovsdb-developer-guide>`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF? Yes, Southbound Connection to OVSDB/Hardware vTEP devices.
-
-* Other security issues?
-
- Plugin's connection to device is by default unsecured. User need to explicitly enable the TLS support through ovsdb
- library configuration file. User can refer to the wiki page
- `here <https://wiki.opendaylight.org/view/OVSDB_Integration:TLS_Communication>`_ for the instructions.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview/coverage?id=org.opendaylight.ovsdb%3Aovsdb>`_ (57%)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/ovsdb/>`_
-*
-* OVSDB southbound plugin is extensively tested through Unit Tests, IT test and system tests. OVSDB southbound plugin
- is tested in both single node setup as well as three node cluster setup. Hardware vTEP plugin is currently tested
- through (1) Unit testing (2) CSIT Tests (3) NetVirt project L2 Gateway features CSIT tests and (4) Manual Testing.
- (3) https://jenkins.opendaylight.org/releng/job/netvirt-csit-1node-openstack-queens-upstream-stateful-oxygen
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
- Yes. User facing features and interfaces are not changed, only enhancements are done.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release? Yes
-* Any API changes? No changes in the YANG models from previous release.
-
-* Any configuration changes? No
-
-Bugs Fixed
-----------
-
-* `List of bugs fixed since the previous release <https://jira.opendaylight.org/issues/?jql=project%20%3D%20OVSDB%20AND%20resolution%20%3D%20Done%20AND%20affectedVersion%20%3D%20Oxygen%20`_
-
-Known Issues
-------------
-
-* List key known issues with workarounds
- None
-* `Link to Open Bugs <https://jira.opendaylight.org/issues/?jql=project%20%3D%20NETVIRT%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20%3D%20Oxygen%20`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in thisrelease
-
- None
-
-Standards
-=========
-
-* `Open vSwitch Database Management Protocol <https://tools.ietf.org/html/rfc7047>`_
-* `OVSDB Schema <http://openvswitch.org/ovs-vswitchd.conf.db.5.pdf>`_
-* `Hardware vTep Schema <http://openvswitch.org/docs/vtep.5.pdf>`_
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/OpenDaylight_OVSDB:Oxygen_Release_Plan>`_
+++ /dev/null
-=========
-P4 Plugin
-=========
-
-odl-p4plugin-all
-----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=p4plugin.git;a=blob;f=features/features-p4plugin/pom.xml
-* **Feature Description:** This is a summary feature containing the default functionalities provided by P4Plugin project.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/p4plugin/job/p4plugin-csit-1node-basic-all-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`p4plugin-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`p4plugin-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * P4Plugin project needs to get node interface resources via NETCONF and the deployed table, and
- to get the channel via gRPC.
-
-* Other security issues?
-
- * Security issues are provided in the RESTCONF and NETCONF projects.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.p4plugin%3Ap4plugin-aggregator>`_
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/p4plugin/job/p4plugin-csit-1node-basic-all-oxygen/>`_
-* Testing methodology. How extensive was it? What should be expected to work?
- What has not been tested as much?
- There are unit tests and integration test available under folder "test",
- but we are now busy with system test in CSIT.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-No, we have no previous release.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release? No, we have no previous release.
-* Any API changes? No.
-* Any configuration changes? No.
-
-Bugs Fixed
-----------
-
-* None.
-
-Known Issues
-------------
-
-* None.
-
-End-of-life
-===========
-
-* None.
-
-Standards
-=========
-
-* None.
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/P4_Plugin:Oxygen:Release_Plan>`_
-* Describe any major shifts in release schedule from the release plan
- None.
+++ /dev/null
-===========
-PacketCable
-===========
-
-Major Features
-==============
-
-odl-packetcable-policy-server
------------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=packetcable.git;a=blob;f=features-packetcable-policy/features4-packetcable-policy/pom.xml;h=0945b9287711a1ce9a7bd6cc0b457607a3cd6248;hb=refs/heads/stable/nitrogen
-* **Feature Description:** Plugin that provides a PCMM model implementation
- based on CMTS structure and COPS protocol. It implements
- `RFC 2748 <https://tools.ietf.org/html/rfc2748>`.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/packetcable/job/packetcable-csit-1node-pcmm-all-oxygen/
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :doc:`Packetcable User Guide <../../user-guide/packetcable-user-guide>`
-
-* **Developer Guide(s):**
-
- * :doc:`Packetcable Developer Guide <../../user-guide/packetcable-user-guide>`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF? No.
-
-* The PacketCable project interfaces to southbound devices using the
- COPS protocol. Securing communication on this interface is outslide
- the scope of this project.
-
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://jenkins.opendaylight.org/releng/view/packetcable/job/packetcable-sonar>`_ ( Test coverage percent - 53.39% )
-
-* Link to CSIT Job:
-* https://jenkins.opendaylight.org/releng/view/packetcable/job/packetcable-csit-1node-pcmm-all-oxygen/
-
-* Other manual testing and QA information - The CSIT job runs the
- PacketCable plugin in a simple cable access controller emulation
- environment. The code is manually tested during the development
- cycle with an actual (controller).
-
-* Testing methodology. There is substantial unit testing executed in
- the project build process; CSIT testing is executed in an "emulated"
- cable access network environment. All product APIs are validated
- during the development cycle. CSIT testing would benefit from an
- upgrade to cover some of the post-Carbon feature additions.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? Yes
- Migration from PacketCable Nitrogen version to the Oxygen version is
- accomplished by replacement of the PacketCable plugin components.
-
-* Any data stored in COPS models will need to be manually replicated.
-
-* All previous API calls will work with the new release.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release? Yes
-* Any API changes? No
-* Any configuration changes? No
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
- NONE
-* The only change for the Oxygen release of Packetcable
- is the upgrade in odlparent version from 2.0.5 to 3.0.2.
-
- Known Issues
--------------
-
-* There are no known issues with the Oxygen release of PacketCable
-
-End-of-life
-===========
-
-* No PacketCable features or APIs are EOLed, deprecated, or removed
- in this release
-
-Standards
-=========
-
-* The Packetcable plug-in implements a subset of the provisioning operations
- defined in these specifications.
-
-* CableLabs "PacketCable 1.5 Specification: MTA Device Provisioning"
- PKT-SP-PROV1.5-I04-090624
-
-* COPS protocol
- RFC 2748 <https://tools.ietf.org/html/rfc2748>
-
-Release Mechanics
-=================
-
-* Link to Packetcable Oxygen release plan:
- <https://wiki.opendaylight.org/view/PacketCablePCMM:Release_Plan_Oxygen>
-* There were no major shifts in release schedule from the release plan
+++ /dev/null
-=========================
-Service Function Chaining
-=========================
-
-Major Features
-==============
-
-odl-sfc-netconf
----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** Provides functionality to communicate with netconf capable Service Functions.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-scf-openflow
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** SFC stand-alone openflow classifier.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-scf-vpp
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** SFC stand-alone vpp classifier.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-openflow-renderer
--------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** Renderer functionality for OpenFlow capable switches.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfclisp
------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** Programs LISP capable switches.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-sb-rest
----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** Implements a South Bound Rest interface to send configuration to REST-capable switches.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-ui
-----------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature is the SFC User Interface.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-vnfm-tacker
--------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** Tacker VNF Manager interface.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-ios-xe-renderer
------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** Renderer functionality for IO XE switches that use netconf.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-vpp-renderer
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** Renderer functionality for fd.io VPP (Vector Packet Processor) switches that use netconf.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-pot
------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature implements a Proof of Transit for the Service Functions.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-statistics
-------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature implements SFC statistics gathering.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-These features are consumed by the User facing features above
-=============================================================
-
-
-odl-sfc-genius
---------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature implements the Genius utilities created by SFC project.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-model
--------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature defines and implements the SFC data model as specified here https://datatracker.ietf.org/doc/rfc7665/
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-pot-netconf-renderer
-----------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature implements the Netconf rendering for the Proof of Transit for the Service Functions.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-provider
-----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature provides an easy-to-use interface to the sfc-model.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-provider-rest
----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature provides no functionality, and just installs the necessary features for SFC restconf.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-ovs
------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature provides functionality for SFC to communicate with OVSDB for SFF configuration.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-odl-sfc-test-consumer
----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sfc.git;a=blob;f=features/src/main/features/features.xml
-* **Feature Description:** This feature is used for testing only.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sfc/job/sfc-csit-3node-clustering-all-carbon
-
-
-Documentation
-=============
-
-* **User Guide(s):**
-
- * :ref:`sfc-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`sfc-dev-guide`
-
-
-Security Considerations
-=======================
-
-None.
-
-
-Quality Assurance
-=================
-
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/sfc/>`_
-* All modules have been unit tested. Integration tests have been performed for
- all major features. System tests have been performed on most major features.
-
-Migration
----------
-
-Nothing special is needed to migrate from the previous release.
-
-Compatibility
--------------
-
-This release of SFC is completely compatible with the previous release.
-The create and delete Rendered Service Path (RSP) RPCs were deprecated
-in this release, but are still available. These RPCs will be removed in
-the next release. Instead of using the RSP RPCs, RSP creation is now
-triggered by Service Function Path (SFP) creation. SFP creation will
-trigger RSP creation in the configuration data store, which will in
-turn trigger RSP creation in the operational data store. Previously,
-RSPs were only stored in the operational data store, which would be
-lost if OpenDaylight restarts. Now it is possible to maintain RSPs
-when OpenDaylight is restarted.
-
-Bugs Fixed
-----------
-
-List of bugs fixed since the previous release
-
-* `SFC-213 <https://jira.opendaylight.org/browse/SFC-213>`_ SFC statistics dont always work
-* `SFC-214 <https://jira.opendaylight.org/browse/SFC-214>`_ Fix sb-rest wiring
-* `SFC-216 <https://jira.opendaylight.org/browse/SFC-216>`_ Fix exception message check for bad macs
-* `SFC-218 <https://jira.opendaylight.org/browse/SFC-218>`_ Fix sfc-scf-vpp wiring
-
-
-Known Issues
-------------
-
-SFC needs changes in OVS to include the Network Service Headers (NSH) Chaining
-encapsulation feature. This patch has been ongoing for quite a while, but has
-finally been officially merged in OVS 2.8. OpenDaylight will be updated to
-use this new version of OVS in the Fluorine release. Until then, SFC will
-use a branched version of OVS based on 2.6.1, called the "Yi Yang Patch",
-`located here <https://github.com/yyang13/ovs_nsh_patches>`_.
-Previous versions of this OVS patch only supported VXLAN-GPE + NSH
-encapsulation, but this version supports both ETH + NSH and
-VXLAN-GPE + ETH + NSH.
-
-* `Link to Open Bugs <https://jira.opendaylight.org/browse/SFC>`_
-
-
-End-of-life
-===========
-
-* None
-
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
-* `IETF SFC RFC <https://datatracker.ietf.org/doc/rfc7665>`_
-* `IETF NSH <https://tools.ietf.org/html/draft-ietf-sfc-nsh-07>`_ Only NSH Metadata type 1 is implemented.
-* `OpenFlow v1.3 <http://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-switch-v1.3.4.pdf>`_
-
-
-Release Mechanics
-=================
-
-* `ODL SFC Oxygen release plan <https://wiki.opendaylight.org/view/Service_Function_Chaining:Oxygen_Release_Plan>`_
-* No major shifts in the release schedule from the release plan
+++ /dev/null
-============
-SNMP Plug-in
-============
-
-Major Features
-==============
-
-odl-snmp-plugin
----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=snmp.git;a=blob;f=features/features-snmp/src/main/features/features.xml;hb=stable/oxygen
-* **Feature Description:** Provides NB API to SB SNMP interface
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:**
-
-Documentation
-=============
-
-* **Getting Started:**
-
- * `SNMP Plugin:Getting Started
- <https://wiki.opendaylight.org/view/SNMP_Plugin:Getting_Started>`_
-
-* **User Guide:**
-
- * :ref:`snmp-plugin-user-guide`
-
-* **SNMP Simulator:**
-
- * `SNMP simulator guide <https://wiki.opendaylight.org/view/SNMP_Plugin:SNMP_Simulator>`_
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- Yes, this plugin provides SNMP endpoints for talking to southbound devices.
-
-* Other security issues?
-
- Securing communication to devices (or not) over SNMP is outside the scope of\
- this project and left to users.
-
-Quality Assurance
-=================
-
-* No Sonar Report
-* No CSIT Jobs
-* Other manual testing and QA information: None
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- Yes, no specific steps needed.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- * Yes
-
-* Any API changes?
-
- * No
-
-* Any configuration changes?
-
- * No
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
- None - no functional change to features
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- No known issues
-
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this release
-
- None
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- * `SNMP <https://www.ietf.org/rfc/rfc1157.txt/>`_
-
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/SNMP_Plugin:Oxygen_Release_Plan>`_
+++ /dev/null
-========
-SNMP4SDN
-========
-
-Major Features
-==============
-
-odl-snmp4sdn-snmp4sdn
----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=snmp4sdn.git;a=tree;f=features;h=d6ff42ff4a927b3f772f63dbc1abceab17cd9e90;hb=db0ab7a12ef59e24fd0d63f1dc21fc60e7fe4c7a
-* **Feature Description:** This feature will install all bundles required for SNMP4SDN Plugin
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** NA, system test waiver
-
-
-Documentation
-=============
-
-* **User Guide:**
-
- * :ref:`snmp4sdn-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`snmp4sdn-dev-guide`
-
-Security Considerations
-=======================
-
-* Switch list file, which is a plain-text file, contains security information such as SNMP community. File access privilege would be carefully set.
-
-* SNMP protocol v2c is used by SNMP4SDN Plugin. SNMP4SDN Plugin configures switches and listens to SNMP
- listen port for link-up/down trap, via SNMP protocol.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=44354>`_ (Test coverage percent NA)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/snmp4sdn/>`_
-* Other manual testing and QA information
-* For each function of SNMP4SDN Plugin, use REST API to confirm it's
- availability and correctness. Existing functions includes flow configuration
- (such as VLAN and forwarding table) and topology discovery.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- No
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- Yes
-
-* Any API changes?
-
- No
-
-* Any configuration changes?
-
- No
-
-
-Bugs Fixed
-----------
-
-* None (no bugs reported since the previous release)
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- None
-
-* `Link to Open Bugs <https://jira.opendaylight.org/projects/SNMP4SDN/>`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this release
-
- None
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- None (no standards implemented, and use a third-party library to configure switches in standard SNMP protocol)
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/SNMP4SDN:Release_Plan_Nitrogen>`_
-* No changes in this release
+++ /dev/null
-==========================================
-Scalable-Group Tag eXchange Protocol (SXP)
-==========================================
-
-Major Features
-==============
-
-odl-sxp-api
------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sxp.git;a=blob;f=features/odl-sxp-api/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature provides models based on
- `RFC <https://tools.ietf.org/pdf/draft-smith-kandula-sxp-05.pdf>`_.
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-sxp-core
-------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sxp.git;a=blob;f=features/odl-sxp-core/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature performs tasks for managing SXP
- devices and provides the implementation of
- `RFC <https://tools.ietf.org/pdf/draft-smith-kandula-sxp-05.pdf>`_.
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-sxp-controller
-------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sxp.git;a=blob;f=features/odl-sxp-controller/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature performs tasks regarding managing SXP
- devices via RESTCONF.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-basic-all-oxygen/
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-filtering-all-oxygen/
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-topology-all-oxygen/
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-3node-periodic-clustering-all-oxygen/
-
-odl-sxp-robot
--------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sxp.git;a=blob;f=features/odl-sxp-robot/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** This is a sample feature used in CSIT testing.
-* **Top Level:** No
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-periodic-performance-all-oxygen/
-
-odl-sxp-routing
--------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=sxp.git;a=blob;f=features/odl-sxp-routing/pom.xml;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature that performs managing of SXP devices
- in cluster environment.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-3node-periodic-routing-all-oxygen/
-
-
-Documentation
-=============
-
-* **Installation Guide(s):**
-
- * `Installation Guide <https://wiki.opendaylight.org/view/SXP:Lithium:Installation_Guide>`_
-
-* **User Guide(s):**
-
- * :ref:`sxp-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`sxp-dev-guide`
-
-Security Considerations
-=======================
-
-* Do you have any external interfaces other than RESTCONF?
-
- * Yes on port 64999 based on `SXP RFC <https://tools.ietf.org/pdf/draft-smith-kandula-sxp-05.pdf>`_ secured by TCP-MD5, optionally also with SSL.
-
-* Other security issues?
-
- * TCP-MD5 security option is now deprecated, and in future will replaced by TCP-AO
-
-Quality Assurance
-=================
-
-* Link to `Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.sxp%3Asxp-parent>`_ (82.4%)
-
-* Link to CSIT Jobs
-
- * `CSIT Job basic <https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-basic-all-oxygen/>`_
- * `CSIT Job filtering <https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-filtering-all-oxygen/>`_
- * `CSIT Job topology <https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-topology-all-oxygen/>`_
- * `CSIT Job clustering <https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-3node-periodic-clustering-all-oxygen/>`_
- * `CSIT Job performance <https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-periodic-performance-all-oxygen/>`_
- * `CSIT Job routing <https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-3node-periodic-routing-all-oxygen/>`_
-
-* Other manual testing and QA information
-
- * N/A
-
-* Testing methodology. How extensive was it? What should be expected to work?
- What hasn't been tested as much?
-
- * `CSIT Test document 1 <https://wiki.opendaylight.org/view/File:SXP_Automated_testing.pdf>`_
- * `CSIT Test document 2 <https://wiki.opendaylight.org/view/File:SXP_Automated_testing_filtering.pdf>`_
- * `CSIT Test document 3 <https://wiki.opendaylight.org/view/File:SXP_Automated_testing_cluster.pdf>`_
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- * Yes, no data models were changed that would break the migration.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
-
- * Functionality is fully backwards compatible.
-
-* Any API changes?
-
- * N/A
-
-* Any configuration changes?
-
- * No
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
- * `Fixed BUGS <https://jira.opendaylight.org/browse/SXP-130?jql=project%20in%20(GBP%2C%20SXP)%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(Resolved%2C%20Verified)%20AND%20created%20%3E%3D%202017-08-14%20AND%20created%20%3C%3D%202018-03-07>`_
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
- * N/A
-
-* `Open Bugs <https://jira.opendaylight.org/browse/SXP-134?jql=project%20%3D%20SXP%20AND%20issuetype%20%3D%20Bug%20AND%20status%20%3D%20Open>`_
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this release
-
- * N/A
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
- * `SXP <https://tools.ietf.org/pdf/draft-smith-kandula-sxp-05.pdf>`_ Fully implemented
-
-Release Mechanics
-=================
-
-* `Release plan <https://wiki.opendaylight.org/view/SXP:Oxygen:Release_Plan>`_
-
-* Describe any major shifts in release schedule from the release plan
-
- * N/A
-
+++ /dev/null
-====
-TSDR
-====
-
-Major Features
-==============
-The Time Series Data Repository (TSDR) project in OpenDaylight (ODL)
-creates a framework for collecting, storing, querying, and maintaining
-time series data from multiple similar and disparate data sources.
-
-* **TSDR Features URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/features-tsdr/pom.xml
-
-odl-tsdr-core
--------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-core/pom.xml
-* **Feature Description:** Core features of TSDR enables collector SPI and external interfaces.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/
-
-
-odl-tsdr-openflow-statistics-collector
---------------------------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-openflow-statistics-collector/pom.xml
-* **Feature Description:** Collect OpenFlow data from the network.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/
-
-odl-tsdr-netflow-collector
---------------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-netflow-statistics-collector/pom.xml
-* **Feature Description:** Collect netflow data from the network.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/
-
-odl-tsdr-restconf-collector
----------------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-restconf-collector/pom.xml
-* **Feature Description:** Collect restconf web activities from the network.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/
-
-odl-tsdr-controller-metrics-collector
--------------------------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-controller-metrics-collector/pom.xml
-* **Feature Description:** Collect ODL controller metrics.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/
-
-odl-tsdr-syslog-collector
--------------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-syslog-collector/pom.xml
-* **Feature Description:** Collect syslog data from the network.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/
-
-odl-tsdr-hsqldb
----------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-hsqldb/pom.xml
-* **Feature Description:** Store the collected data into hsqldb that is embedded in ODL controller.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/job/tsdr-csit-verify-1node-hsqldb-datastore/
-
-odl-tsdr-hbase
---------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-hbase/pom.xml
-* **Feature Description:** Store the collected data into hbase data store.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/job/tsdr-csit-verify-1node-hbase-datastore/
-
-odl-tsdr-hbase-client
----------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-hbaseclient/pom.xml
-* **Feature Description:** External facing client to store the collected data into hbase data store.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/job/tsdr-csit-verify-1node-hbase-datastore/
-
-odl-tsdr-cassandra
-------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-cassandra/pom.xml
-* **Feature Description:** Store the collected data into cassandra data store.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/job/tsdr-csit-verify-1node-cassandra-datastore/
-
-odl-tsdr-elasticsearch
-----------------------
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=tsdr.git;a=blob;f=features/odl-tsdr-elasticsearch/pom.xml
-* **Feature Description:** Store the collected data into ElasticSearch data store.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/tsdr/job/tsdr-csit-verify-1node-elasticsearch-datastore/
-
-Documentation
-=============
-
-Please provide the URL to each document at docs.opendaylight.org. If the document is under review, provide a link to the change in Gerrit.
-
-* **Installation Guide(s):**
-
- * :ref:`TSDR Installation Guide <tsdr-install-guide>`
-
-* **User Guide(s):**
-
- * :ref:`TSDR User Guide <tsdr-user-guide>`
-
-* **HSQLDB TSDR User Guide:** https://github.com/opendaylight/docs/blob/stable/lithium/manuals/user-guide/src/main/asciidoc/tsdr/tsdr-hsqldb-user.adoc
-* **HBase TSDR User Guide:** https://github.com/opendaylight/docs/blob/stable/lithium/manuals/user-guide/src/main/asciidoc/tsdr/tsdr-hbase-user.adoc
-
-Security Considerations
-=======================
-
-* TSDR northbound query supports authentication and authorization using AAA features.
-* Since ODL OpenFlow Plugin supports TLS, the OpenFlow Stats data transported from OpenFlow enabled appliances to ODL will be encrypted when TLS is enabled.
-* Syslog, NetFlow, and RestConf collectors do not support encryption at this time.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.tsdr%3Atsdr>`_ 73.1%
-* `Link to Test Procedures <https://wiki.opendaylight.org/view/TSDR:TSDR_Oxygen_Testing_with_Results#Test_Cases_.26_Results/>`_
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/tsdr/>`_
-* `Other manual testing and QA information <https://wiki.opendaylight.org/view/TSDR_Carbon_:TSDR_Integration_System_Test/>`_
-* Testing methodology. How extensive was it? What should be expected to work? What hasn't been tested as much?
-
- * Relying on automation for regression on features carried over from previous releases. Manual testing on new features with test report.
-
-Migration
----------
-
-* Is it possible to migrate from the previous release? If so, how?
-
- * Yes, since there's no change of features from the previous releases.
-
-Compatibility
--------------
-
-* Is this release compatible with the previous release?
- Yes.
-
-* Any API changes?
- No.
-
-* Any configuration changes?
- No.
-
-Bugs Fixed
-----------
-
-* List of bugs fixed since the previous release
-
-Known Issues
-------------
-
-* List key known issues with workarounds
-
-End-of-life
-===========
-
-* List of features/APIs which are EOLed, deprecated, and/or removed in this release
-
- * SNMP data collector was temporarily removed.
-
-Standards
-=========
-
-* List of standards implemented and to what extent
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/TSDR:TSDR_Oxygen_Release_Plan>`_
-* Describe any major shifts in release schedule from the release plan
- * N/A.
+++ /dev/null
-======================
-Unified Secure Channel
-======================
-
-Major Features
-==============
-
-* USC Agent provides proxy and agent functionality on top of all standard
- protocols supported by the device. It initiates call-home with the controller,
- maintains live connections with with the controller, acts as a demuxer/muxer
- for packets with the USC header, and authenticates the controller.
-* USC Plugin is responsible for communication between the controller and the USC
- agent . It responds to call-home with the controller, maintains live
- connections with the devices, acts as a muxer/demuxer for packets with the USC
- header, and provides support for TLS/DTLS.
-* USC Manager handles configurations, high availability, security, monitoring,
- and clustering support for USC.
-* USC UI is responsible for displaying a graphical user interface representing
- the state of USC in the OpenDaylight DLUX UI.
-
-USC Channel UI
---------------
-
-* **Feature Name:** odl-usc-channel-ui
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=usc.git;a=blob;f=usc-features/odl-usc-channel-ui/pom.xml;
-* **Feature Description:** Responsible for communication between the controller
- and the USC agent . It responds to call-home with the controller, maintains
- live connections with the devices, acts as muxer/demuxer for packets with the
- USC header, and provides support for TLS/DTLS.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/usc
-
-Documentation
-=============
-
-Please provide the URL to each document at docs.opendaylight.org. If the
-document is under review, provide a link to the change in Gerrit.
-
-* **User Guide(s):**
-
- * :ref:`usc-user-guide`
-
-* **Developer Guide(s):**
-
- * :ref:`usc-dev-guide`
-
-Security Considerations
-=======================
-
-* USC uses TLS and DTLS to secure the channels. Asymmetric authentication
- handshake when establishing the channels. Mutual authentication achieved with
- certificates configured in usc.properties for both the controller and the
- device.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=44336>`_
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/usc>`_
-* `Link to Additional Details <https://wiki.opendaylight.org/view/USC:Integration_Test>`_
-* Code is covered by unit and integration tests
-* System Tests are performed by CSIT jobs using java test agent.
-
-
-Migration
----------
-
-* Nothing beyond general OpenDaylight migration requirements.
-
-Compatibility
--------------
-
-* Nothing beyond general OpenDaylight compatibility constraints.
-
-Bugs Fixed
-----------
-
-* `USC Bugs List <https://jira.opendaylight.org/projects/USC>`_
-
-Known Issues
-------------
-
-* `USC-12 <https://jira.opendaylight.org/browse/USC-12>`_ USC features has configuration issues with 3-node cluster environment.
-
-End-of-life
-===========
-
-* Nothing deprecated, EOL.
-
-Standards
-=========
-
-* N/A
-
-Release Mechanics
-=================
-
-* `USC Release Plan <https://wiki.opendaylight.org/view/USC:Release_Plan>`_
-* Project was on schedule
+++ /dev/null
-===============================
-Honeycomb Virtual Bridge Domain
-===============================
-
-Major Features
-==============
-
-odl-vbd
--------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=honeycomb/vbd.git;a=blob;f=features/odl-vbd/src/main/feature/feature.xml;h=37a666153982e4efa38a37ca0b971be5d5cbdcd6;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature provides models to configure Virtual Bridge Domains on VPP.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-odl-vbd-ui
-----------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=honeycomb/vbd.git;a=tree;f=features/odl-vbd-ui;h=a6172d7fb3d2c1930b0a87213b7043f58a711f60;hb=refs/heads/stable/oxygen
-* **Feature Description:** This feature provides the GUI for VBD.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** Yes
-* **CSIT Test:** N/A
-
-
-Documentation
-=============
-
-* `Wiki <https://wiki.opendaylight.org/view/Honeycomb/VBD>`_
-* `VBD API <https://wiki.opendaylight.org/view/Honeycomb/VBD/API>`_
-
-Security Considerations
-=======================
-
-* N/A
-
-Quality Assurance
-=================
-
-* `Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.honeycomb.vbd%3Avbd-aggregator>`_ (0% - no coverage results available)
-
-Migration
----------
-
-* Please use VPP 17.04 stable.
-
-Compatibility
--------------
-
-* Not compatible with previous VPP 17.01 or older stable versions.
-
-Bugs Fixed
-----------
-
-* N/A
-
-
-Known Issues
-------------
-
-* N/A
-
-End-of-life
-===========
-
-* N/A
-
-Standards
-=========
-
-* N/A
-
-Release Mechanics
-=================
-
-* `Release plan <https://wiki.opendaylight.org/view/Honeycomb/VBD/Oxygen/Release_Plan>`_
-* no major shifts from official release plan
+++ /dev/null
-===
-VTN
-===
-
-Major Features
-==============
-
-odl-vtn-manager-rest
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=vtn.git;a=blob;f=manager/features/odl-vtn-manager-rest/pom.xml;h=f47f7681bc04f054e8dbaa69a01ae600ef9e60b7;hb=refs/heads/stable/oxygen#l24
-* **Feature Description:** This is the feature that allows users to use the VTN virtualization, by creating the various components as needed for the network.
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-csit-1node-manager-all-oxygen/
-
-
-odl-vtn-manager-neutron
-----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=vtn.git;a=blob;f=manager/features/odl-vtn-manager-neutron/pom.xml;h=39c9d48dd430f5970860566a5f888b4b6c269992;hb=refs/heads/stable/oxygen#l24
-* **Feature Description:** This feature provides support for integration with Openstack (L2 API)
-* **Top Level:** Yes
-* **User Facing:** Yes
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/vtn/job/vtn-csit-1node-openstack-pike-neutron-oxygen/
-
-Documentation
-=============
-
-* **Installation Guide(s):**
-
- * :ref:`vtn-install-guide`
-
-* **User Guide(s):**
-
- * :ref:`VTN User Guide <vtn-user-guide>`
-
-* **Developer Guide(s):**
-
- * :ref:`VTN Developer Guide <vtn-dev-guide>`
- * :ref:`VTN Openstack Developer Guide <vtn-openstack-dev-guide>`
-
-Security Considerations
-=======================
-
-* No Issues.
-
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.vtn%3Adistribution&did=1>`_ (56.2%)
-* `Link to CSIT Jobs <https://jenkins.opendaylight.org/releng/view/vtn/>`_
-* CSIT covers most of the options in RESTCONF
-* The 3 node deployment is experimental and not well tested.
-
-Migration
----------
-
-* Not Supported.
-
-Compatibility
--------------
-
-* No Specific Compatibility issues.
-
-Bugs Fixed
-----------
-
-* vtn-164 - VTN Coordinator Flowlistentry Creation fails for "port-from" and "port-to"
-* vtn-165 - UDP L4 match details of source and destination creation failure in Flowlistentry
-* vtn-166 - vtn-inet-match protocol and dscp values not mapped from VTN Coordinator to VTN manager
-* vtn-167 - VTN Coodinator: Upgrading Tomcat to 7.0.81
-
-Known Issues
-------------
-
-* `Link to Open Bugs <https:jira.opendaylight.org/browse/VTN>`_
-
-End-of-life
-===========
-
-* None
-
-Standards
-=========
-
-* None
-
-Release Mechanics
-=================
-
-* `Link to release plan <https://wiki.opendaylight.org/view/VTN:Oxygen_Release_Plan>`_
-* There was no deviation from the plan.
+++ /dev/null
-==========
-YANG Tools
-==========
-
-Major Features
-==============
-
-Oxygen release marks the eighth release of YANG Tools components. The focus
-of this release was to clean up deprecated APIs and perform maintenance
-which requires breaking API compatibility -- hence producing a 2.0.x release
-train.
-
-Major items delivered are:
-* Split up yang-parser-impl, allowing components to be plugged more cleanly
-* Remove use of Guava's Optional in favor of Java 8's equivalent
-* Define yang-parser-api
-* Mandatory leaves are enforced by default
-* RFC7951-compliant JSON codec
-* Features have been split into stable and experimental
-* Old XML parser has been removed
-* YANG model revisions are represented via a dedicated class, not Date
-* YANG type empty is represented as a dedicated class, not Void
-
-odl-triemap
------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-triemap/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install concurrent-hash-trie-based Map implementation
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-yangtools-codec
--------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-common/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install JSON and XML parsers
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-yangtools-common
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-common/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install common concepts and utilities.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-yangtools-data-api
-----------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-data-api/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install YANG Data APIs.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-yangtools-data
-------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-data/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install YANG Data implementation.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-yangtools-export
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-export/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install YANG model export utilities.
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-yangtools-parser-api
-------------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-parser-api/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install YANG model APIs
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-yangtools-parser
---------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-parser/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install YANG Parser
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** https://jenkins.opendaylight.org/releng/view/yangtools/job/yangtools-csit-1node-periodic-system-only-oxygen/
-
-odl-yangtools-xpath
--------------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-yangtools-xpath/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install XPath evaluation engine
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** No
-* **CSIT Test:** System test waiver request pending.
-
-odl-exp-objcache
-----------------
-
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=yangtools.git;a=blob_plain;f=features/odl-exp-objcache/pom.xml;hb=refs/tags/v2.0.1
-* **Feature Description:** to install Object Cache APIs and implementation
-* **Top Level:** Yes
-* **User Facing:** No
-* **Experimental:** Yes
-* **CSIT Test:** System test waiver request pending.
-
-Documentation
-=============
-* **Developer Guide(s):**
-
- * :ref:`yangtools-developer-guide`
-
-Security Considerations
-=======================
-
-* YANG Tools libraries are designed to be embedded and not to be a stand-alone
- application so security concerns need to be addressed by the application
- using this library.
-
-Quality Assurance
-=================
-
-* `Link to Sonar Report <https://sonar.opendaylight.org/dashboard?id=org.opendaylight.yangtools%3Ayangtools-aggregator>`_
- Test coverage 62.3%, which constitutes a drop by 12%. This is caused by the parser being more modular, hence tests which
- previously accounted to code coverage are no longer counted. We will address this with targeted unit tests if following
- releases.
-* `Link to CSIT Jobs
- <https://jenkins.opendaylight.org/releng/view/yangtools/job/yangtools-csit-1node-periodic-system-only-oxygen/>`_
-
-Migration
----------
-
-* This release constitutes a major shift in all APIs exposed by yangtools. Code
- users need to adjust their feature refences and adjust to changed method
- signatures. Most users should not be impacted as they should be interacting
- with MD-SAL.
-
-Compatibility
--------------
-
-* Release is not compatible with the previous one. The APIs changed are too numerous to list here.
-
-* No configuration changes.
-
-* Behavior changes:
- * Mandatory leaf presence is enforced by default
- * Pattern invert-match modifier is honored in both JSON and XML codecs
-
-Bugs Fixed
-----------
-
-* List of fixed `Bugs <https://jira.opendaylight.org/issues/?jql=project%20%3D%20YANGTOOLS%20AND%20fixVersion%20%3D%202.0.0%20OR%20fixVersion%20%3D%202.0.1>`
-
-Known Issues
-------------
-
-* List of open `Bugs <https://jira.opendaylight.org/issues/?jql=project%20%3D%20YANGTOOLS%20AND%20affectedVersion%20%3D%202.0.1?`
-
-End-of-life
-===========
-
-* odl-exp-objcache is marked as experimental and will be removed in the next
- major (3.0.0) release.
-
-* This release contains deprecated API elements in all code artifacts. These
- will be removed in the next major (3.0.0) release.
-
-* All API elements are expected to remain compatible for at least the duration
- of Fluorine release cycle.
-
-Standards
-=========
-
-* YANG and YIN parser processing according to
- `RFC 6020 <https://tools.ietf.org/html/rfc6020>`_,
- `RFC 6536 <https://tools.ietf.org/html/rfc6536>`_,
- `RFC 7950 <https://tools.ietf.org/html/rfc7950>`_,
- `RFC 7952 <https://tools.ietf.org/html/rfc7950>`_ and
- `RFC 8040 <https://tools.ietf.org/html/rfc8040>`_
-* XML parser for YANG-modeled data according to
- `RFC 6020 <https://tools.ietf.org/html/rfc6020>`_ and
- `RFC 7950 <https://tools.ietf.org/html/rfc7950>`_.
-* JSON parser for YANG-modeled data according to
- `RFC 7951 <https://tools.ietf.org/html/rfc7951>`_
-
-Release Mechanics
-=================
-
-* `Link to the release plan <https://wiki.opendaylight.org/view/Simultaneous_Release:Oxygen_Release_Plan>`_
---------------------------
The Managed Release Model will reduce the overhead both on projects taking
-part in the Managed Release and Unmanaged Projects.
+part in the Managed Release and Self-Managed Projects.
Managed Projects will have fewer, smaller checkpoints consisting of only
information that is maximally helpful for driving the release process. Much of
that can break the jobs they depend on will be a smaller set, more stable and
more responsive.
-Projects that are Unmanaged will have less overhead and reporting. They will
+Projects that are Self-Managed will have less overhead and reporting. They will
be free to develop in their own way, providing their artifacts to include in
the final release or choosing to release on their own schedule. They will not
be required to submit any checkpoints and will not be expected to work closely
Managed Projects should only depend on other Managed Projects.
-If a project wants to be Managed but depends on Unmanaged Projects, they
+If a project wants to be Managed but depends on Self-Managed Projects, they
should work with their dependencies to become Managed at the same time or
-drop any Unmanaged dependencies.
+drop any Self-Managed dependencies.
Documentation
+++++++++++++
for external communication, such as marketing to users or a report to
other LFN projects or the LFN Board.
-* If a project is transitioning from Unmanaged to Managed or applying for
+* If a project is transitioning from Self-Managed to Managed or applying for
the first time into a Managed release, raise a Jira **Project Plan** issue
against the TSC project highlighting the request.
* Select the release version in the **ODL Release** field
- * Select the ``NOT_Integrated (Unmanaged)`` value in the **ODL Participation**
+ * Select the ``NOT_Integrated (Self-Managed)`` value in the **ODL Participation**
field
* Select the appropriate value in the **ODL New Participation** field:
.. code-block:: none
Summary
- This is an example of a request for a project to move from Unmanaged to
- Managed. It should be submitted no later than the start of the release.
- The request should make it clear that the requesting project meets all
- of the Managed Release Requirements.
+ This is an example of a request for a project to move from Self-Managed
+ to Managed. It should be submitted no later than the start of the
+ release. The request should make it clear that the requesting project
+ meets all of the Managed Release Requirements.
Healthy Community
The request should make it clear that the requesting project has a
may also show that the project has a history of dealing with CLM
violations in a timely manner.
-* If a project is transitioning from Managed to Unmanaged, raise a Jira
+* If a project is transitioning from Managed to Self-Managed, raise a Jira
**Project Plan** issue against the TSC project highlighting the request.
* Select your project in the **ODL Project** field
* Select the appropriate value in the **ODL Participation** field:
``SNAPSHOT_Integrated (Managed)`` or ``RELEASE_Integrated (Managed)``
- * Select the ``NOT_Integrated (Unmanaged)`` value in the
+ * Select the ``NOT_Integrated (Self-Managed)`` value in the
**ODL New Participation** field
* In the **Summary** field, put something like:
- ``Project-X Fluorine Joining/Moving to Unmanged for Fluorine``
+ ``Project-X Fluorine Joining/Moving to Self-Manged for Fluorine``
* In the **Description** field, fill in the details:
.. code-block:: none
- This is a request for a project to move from Unmanged to Managed. It
+ This is a request for a project to move from Self-Managed to Managed. It
should be submitted no later than the start of the release. The request
does not require any additional information, but it may be helpful for
the requesting project to provide some background and their reasoning.
cover everything they expect to do in the next Managed Release, which may
encompass any number of major version bumps for the MRI Projects.
-Moving a Project from Unmanaged to Managed
-------------------------------------------
+Moving a Project from Self-Managed to Managed
+---------------------------------------------
-Unmanaged Projects can request to become Managed by submitting a
+Self-Managed Projects can request to become Managed by submitting a
**Project_Plan** issue to the TSC project in Jira. See details as described
under the `Initial Checkpoint`_ section above. Requests should be submitted
before the start of a release. The requesting project should make it clear that
* odlparent
* yangtools
-Unmanaged Projects
-==================
+Self-Managed Projects
+=====================
-Requirements for Unmanaged Projects
------------------------------------
+Requirements for Self-Managed Projects
+--------------------------------------
-Unmanaged Project requirements are designed to be as low-overhead as possible
-while still allowing for participation in the final release. If Unmanaged
-Projects do not want to participate in the final release and instead provide
-their artifacts to their consumers through another channel, there are no
-requirements.
+Self-Managed Project requirements are designed to be as low-overhead as
+possible while still allowing for participation in the final release. If
+Self-Managed Projects do not want to participate in the final release and
+instead provide their artifacts to their consumers through another channel,
+there are no requirements.
SNAPSHOT Versions by Release
++++++++++++++++++++++++++++
-Unmanaged Projects can consume whichever version of their upstream dependencies
-they want during most of the release cycle, but if they want to be included in
-the final release distribution they must bump their versions to SNAPSHOT no
-later than one week before code freeze.
+Self-Managed Projects can consume whichever version of their upstream
+dependencies they want during most of the release cycle, but if they want to be
+included in the final release distribution they must bump their versions to
+SNAPSHOT no later than one week before code freeze.
-Jobs Required for Unmanaged Projects Running
-++++++++++++++++++++++++++++++++++++++++++++
+Jobs Required for Self-Managed Projects Running
++++++++++++++++++++++++++++++++++++++++++++++++
-Unmanaged Projects that wish to take part in the final release must enable the
-validate-autorelease job. Unmanaged Projects can release artifacts at any time
-using the release job. To take part in the final release, Unmanaged Projects
-will need to run the release job with the version of the final distribution no
-later than one week before code freeze.
+Self-Managed Projects that wish to take part in the final release must enable
+the validate-autorelease job. Self-Managed Projects can release artifacts at
+any time using the release job. To take part in the final release, Self-Managed
+Projects will need to run the release job with the version of the final
+distribution no later than one week before code freeze.
Added to Final Distribution POM
+++++++++++++++++++++++++++++++
-In order to be included in the final distribution, Unmanaged Projects must
+In order to be included in the final distribution, Self-Managed Projects must
submit a patch to include themselves in the final distribution pom.xml file no
-later than one week before code freeze. Projects should only be added to the final
-distribution pom.xml after they have published artifacts with the release job
-to avoid breaking the build.
+later than one week before code freeze. Projects should only be added to the
+final distribution pom.xml after they have published artifacts with the release
+job to avoid breaking the build.
-Unmanaged Release Process
--------------------------
+Self-Managed Release Process
+----------------------------
-Unmanaged Projects are free to follow their own processes. To have their
+Self-Managed Projects are free to follow their own processes. To have their
artifacts included in the final distribution, they need only follow the
-Requirements for Unmanaged Projects above by the deadlines. Note that Unmanaged
-Projects will not have any leeway for missing deadlines. If projects are not
-in the final distribution by one week before code freeze their artifacts will not be
-included in the final release, but they may still publish artifacts and help
-their consumers install them out-of-band.
+Requirements for Self-Managed Projects above by the deadlines. Note that
+Self-Managed Projects will not have any leeway for missing deadlines. If
+projects are not in the final distribution by one week before code freeze their
+artifacts will not be included in the final release, but they may still publish
+artifacts and help their consumers install them out-of-band.
Checkpoints
+++++++++++
-There are no checkpoints for Unmanaged Projects.
+There are no checkpoints for Self-Managed Projects.
-Moving a Project from Managed to Unmanaged
-------------------------------------------
+Moving a Project from Managed to Self-Managed
+---------------------------------------------
Managed Projects that are not required for dependency reasons can submit a
-**Project_Plan** issue to be Unmanaged to the TSC project in Jira. See details
+**Project_Plan** issue to be Self-Managed to the TSC project in Jira. See details
in the `Initial Checkpoint`_ section above. Requests should be submitted before
the start of a release. Requests will be evaluated by the TSC.
The TSC may withdraw a project from the Managed Release at any time.
-Installing Features from Unmanaged Projects
--------------------------------------------
+Installing Features from Self-Managed Projects
+----------------------------------------------
-Unmanaged Projects will have their artifacts included in the final release if
-they are available on-time, but they will not be available to be installed
+Self-Managed Projects will have their artifacts included in the final release
+if they are available on-time, but they will not be available to be installed
until the user does a repo:add.
-To install an Unmanaged Project feature, find the feature description in the
+To install an Self-Managed Project feature, find the feature description in the
system directory. For example, NetVirt's main feature:
system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/
* In the **ODL_Gerrit_Patch**, put in a URL to a Gerrit patch, if applicable
-Release Schedule
-================
-
-The start date for odd release is September 7 and the start date for even
-release is March 7.
-
-.. list-table::
- :widths: 20 20 20 40
- :header-rows: 1
- :stub-columns: 1
-
- * - **Milestone**
- - **Time**
- - **Fluorine**
- - **Description**
-
- * - Release Start
- - Start Date
- - 2018-03-07
- - Declare Intention: Submit **Project_Plan** Jira item in TSC project
-
- * - Initial Checkpoint
- - Start Date + 2 weeks
- - 2018-03-22
- - Initial Checkpoint. All Managed Projects must have completed
- **Project_Plan** Jira items in TSC project.
-
- * - Release Integrated Deadline
- - Initial Checkpoint + 2 weeks
- - 2018-04-07
- - Deadline for Release Integrated Projects (currently ODLPARENT and
- YANGTOOLS) to provide the desired version deliverables for downstream
- Snapshot Integrated Projects to consume.
-
- * - Version Bump
- - Release Integrated Deadline + 1 day
- - 2018-04-08
- - Prepare version bump patches and merge them in (RelEng team). Spend the
- next 2 weeks to get green build for all MSI Projects and a healthy
- distribution.
-
- * - Version Bump Checkpoint
- - Release Integrated Deadline + 2 weeks
- - 2018-04-21
- - Check status of MSI Projects to see if we have green builds and a
- healthy distribution. Revert the MRI deliverables if deemed necessary.
-
- * - CSIT Checkpoint
- - Version Bump Checkpoint + 2 weeks
- - 2018-05-07
- - All Managed Release CSIT should be in good shape - get all MSI Projects'
- CSIT results as they were before the version bump. This is the final
- opportunity to revert the MRI deliverables if deemed necessary.
-
- * - Middle Checkpoint
- - CSIT Checkpoint + 8 weeks
- - 2018-07-05
- - Checkpoint for status of Managed Projects - especially Snapshot
- Integrated Projects.
-
- * - Code Freeze
- - Middle Checkpoint + 4 weeks
- - 2018-08-07
- - Code freeze for all Managed Projects - cut and lock release branch. Only
- allow blocker bugfixes in release branch.
-
- * - Final Checkpoint
- - TSC meeting 2 weeks after Code Freeze
- - 2018-08-23
- - Final Checkpoint for all Managed Projects.
-
- * - Formal Release
- - 6 months after Start Date
- - 2018-09-07
- - Formal release
-
- * - Service Release 1
- - 1 month after Formal Release
- - 2018-10-07
- - Service Release 1 (SR1)
-
- * - Service Release 2
- - 2 months after SR1
- - 2018-12-07
- - Service Release 2 (SR2)
-
- * - Service Release 3
- - 2 months after SR2
- - 2019-02-07
- - Service Release 3 (SR3)
-
- * - Service Release 4
- - 3 months after SR3
- - 2019-05-07
- - Service Release 4 (SR4) - final service release
-
- * - Release End of Life
- - 4 months after SR4
- - 2019-09-07
- - End of Life - coincides with the Formal Release of the current release+2
- versions and the start of the current release+3 versions
-
Vocabulary Reference
====================
* Managed Release Process: The release process described in this document.
* Managed Project: A project taking part in the Managed Release Process.
-* Unmanaged Project: A project not taking part in the Managed Release Process.
+* Self-Managed Project: A project not taking part in the Managed Release
+ Process.
* Simultaneous Release: Event wherein all Snapshot Integrated Project versions
are rewriten to release versions and release artifacts are produced.
* Snapshot Integrated Project: Project that integrates with OpenDaylight
Release Schedule
================
-While OpenDaylight has always targeted two releases per year, in practice our
-release process for the first six releases (through Carbon) has, in practice,
-released approximately every 8 months. This has meant we don't quite release
-twice a year (Lithium was our only release in 2015) and we struggle to
-coordinate releases with other projects that release at regular times each
-year, e.g., OpenStack and OPNFV.
-
-To try to fix this, we had a short Nitrogen release and then we move to
-a date-based, six-month release calendar releasing at the same time each year.
-Oxygen is the first date-based release of 2018.
-
-Oxygen
-========
-
-+-----------+------------+------------+------------+----------------------------------------+
-| Milestone | offset 0 | offset 1 | offset 2 | Description |
-+===========+============+============+============+========================================+
-| M0 | 2017/09/07 | 2017/09/07 | 2017/09/07 | Declare Intent |
-+-----------+------------+------------+------------+----------------------------------------+
-| M1 | 2017/10/07 | 2017/10/14 | 2017/10/21 | Final Release Plan, Project Setup |
-+-----------+------------+------------+------------+----------------------------------------+
-| M2 | 2017/11/07 | 2017/11/14 | 2017/11/21 | Functionality Freeze |
-+-----------+------------+------------+------------+----------------------------------------+
-| M3 | 2017/12/07 | 2017/12/14 | 2017/12/21 | API Freeze |
-+-----------+------------+------------+------------+----------------------------------------+
-| M4 | 2018/01/07 | 2018/01/14 | 2018/01/21 | Code Freeze *(note M3-M4 will likely |
-| | | | | be short since it includes 12/25-1/1)* |
-+-----------+------------+------------+------------+----------------------------------------+
-| RC0 | 2018/02/07 | N/A | N/A | All projects must be in the |
-| | | | | distribution and autorelease |
-+-----------+------------+------------+------------+----------------------------------------+
-| RC1 | 2018/02/14 | N/A | N/A | Lock branches |
-+-----------+------------+------------+------------+----------------------------------------+
-| RC2 | 2018/02/21 | N/A | N/A | Only merge blocking bugs |
-+-----------+------------+------------+------------+----------------------------------------+
-| RC3 | 2018/02/28 | N/A | N/A | Release Reviews, All known blockers |
-| | | | | addressed/merged |
-+-----------+------------+------------+------------+----------------------------------------+
-| Release | 2018/03/07 | | | |
-+-----------+------------+------------+------------+----------------------------------------+
-| SR1 | 2018/04/07 | | | |
-+-----------+------------+------------+------------+----------------------------------------+
-| SR2 | 2018/06/07 | | | |
-+-----------+------------+------------+------------+----------------------------------------+
-| SR3 | 2018/08/07 | | | |
-+-----------+------------+------------+------------+----------------------------------------+
-| SR4 | 2018/09/21 | | | |
-| | - | | | |
-| | 2018/11/07 | | | |
-+-----------+------------+------------+------------+----------------------------------------+
-
-.. note:: Dates are calendar based on the 7th, 14th, 21st, and 28th of each month instead of being
- on a particular day of the week. The intent is that projects will figure out how to meet
- the deadline in the way that best works for them even if that means getting work done
- ahead of time to avoid holidays, weekends, vacation or travel.
-
-Future Odd Releases
-===================
-
-Starting with Oxygen, our odd-numbered element releases will look like this:
-
-+-----------+-----------+-------+-------+----------------------------------------+
-| Milestone | off0 | off1 | off2 | Description |
-+===========+===========+=======+=======+========================================+
-| M0 | 9/7 | | | Draft Release Plan |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M1 | 10/7 | 10/14 | 10/21 | Final Release Plan, Project Setup |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M2 | 11/7 | 11/14 | 11/21 | Functionality Freeze |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M3 | 12/7 | 12/14 | 12/21 | API Freeze |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M4 | 1/7 | 1/14 | 1/21 | Code Freeze *(note M3-M4 will likely |
-| | | | | be short since it includes 12/25-1/1)* |
-+-----------+-----------+-------+-------+----------------------------------------+
-| RCs | 1/21-3/7 | | | (continuous build) |
-+-----------+-----------+-------+-------+----------------------------------------+
-| Release | 3/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR1 | 4/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR2 | 6/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR3 | 8/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR4 | 9/21-11/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-
-Future Even Releases
-====================
-
-Starting with Fluorine, our even-numbered element releases will look like this:
-
-+-----------+-----------+-------+-------+----------------------------------------+
-| Milestone | off0 | off1 | off2 | Description |
-+===========+===========+=======+=======+========================================+
-| M0 | 3/7 | | | Draft Release Plan |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M1 | 4/7 | 4/14 | 4/21 | Final Release Plan, Project Setup |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M2 | 5/7 | 5/14 | 5/21 | Functionality Freeze |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M3 | 6/7 | 6/14 | 6/21 | API Freeze |
-+-----------+-----------+-------+-------+----------------------------------------+
-| M4 | 7/7 | 7/14 | 7/21 | Code Freeze |
-+-----------+-----------+-------+-------+----------------------------------------+
-| RCs | 7/21-9/7 | | | (continuous build) |
-+-----------+-----------+-------+-------+----------------------------------------+
-| Release | 9/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR1 | 10/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR2 | 12/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR3 | 2/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
-| SR4 | 3/21-5/7 | | | |
-+-----------+-----------+-------+-------+----------------------------------------+
+In an attempt to synchronize with other related open source projects
+(e.g., OPNFV and OpenStack), OpenDaylight releases twice per year on
+a 6 month cadence. These releases are scheduled for September 7th
+and March 7th. These release dates are also used as the beginning
+for the subsequent release.
+
+.. list-table::
+ :widths: 20 20 20 40
+ :header-rows: 1
+ :stub-columns: 1
+
+ * - **Milestone**
+ - **Time**
+ - **Fluorine**
+ - **Description**
+
+ * - Release Start
+ - Start Date
+ - 2018-03-07
+ - Declare Intention: Submit **Project_Plan** Jira item in TSC project
+
+ * - Initial Checkpoint
+ - Start Date + 2 weeks
+ - 2018-03-22
+ - Initial Checkpoint. All Managed Projects must have completed
+ **Project_Plan** Jira items in TSC project.
+
+ * - Release Integrated Deadline
+ - Initial Checkpoint + 2 weeks
+ - 2018-04-07
+ - Deadline for Release Integrated Projects (currently ODLPARENT and
+ YANGTOOLS) to provide the desired version deliverables for downstream
+ Snapshot Integrated Projects to consume.
+
+ * - Version Bump
+ - Release Integrated Deadline + 1 day
+ - 2018-04-08
+ - Prepare version bump patches and merge them in (RelEng team). Spend the
+ next 2 weeks to get green build for all MSI Projects and a healthy
+ distribution.
+
+ * - Version Bump Checkpoint
+ - Release Integrated Deadline + 2 weeks
+ - 2018-04-21
+ - Check status of MSI Projects to see if we have green builds and a
+ healthy distribution. Revert the MRI deliverables if deemed necessary.
+
+ * - CSIT Checkpoint
+ - Version Bump Checkpoint + 2 weeks
+ - 2018-05-07
+ - All Managed Release CSIT should be in good shape - get all MSI Projects'
+ CSIT results as they were before the version bump. This is the final
+ opportunity to revert the MRI deliverables if deemed necessary.
+
+ * - Middle Checkpoint
+ - CSIT Checkpoint + 8 weeks
+ - 2018-07-05
+ - Checkpoint for status of Managed Projects - especially Snapshot
+ Integrated Projects.
+
+ * - Code Freeze
+ - Middle Checkpoint + 4 weeks
+ - 2018-08-07
+ - Code freeze for all Managed Projects - cut and lock release branch. Only
+ allow blocker bugfixes in release branch.
+
+ * - Final Checkpoint
+ - TSC meeting 2 weeks after Code Freeze
+ - 2018-08-23
+ - Final Checkpoint for all Managed Projects.
+
+ * - Formal Release
+ - 6 months after Start Date
+ - 2018-09-07
+ - Formal release
+
+ * - Service Release 1
+ - 1 month after Formal Release
+ - 2018-10-07
+ - Service Release 1 (SR1)
+
+ * - Service Release 2
+ - 2 months after SR1
+ - 2018-12-07
+ - Service Release 2 (SR2)
+
+ * - Service Release 3
+ - 2 months after SR2
+ - 2019-02-07
+ - Service Release 3 (SR3)
+
+ * - Service Release 4
+ - 3 months after SR3
+ - 2019-05-07
+ - Service Release 4 (SR4) - final service release
+
+ * - Release End of Life
+ - 4 months after SR4
+ - 2019-09-07
+ - End of Life - coincides with the Formal Release of the current release+2
+ versions and the start of the current release+3 versions
+++ /dev/null
-Subproject commit 1f41c70c0fb1dce125292056afc56cc7847c488a
+++ /dev/null
-Subproject commit 6ab99020ed1abe5324ff33075e5642be4feb9564
+++ /dev/null
-Subproject commit 460cf6e2fd7cb207b75e429d9ee482b1ec7cf97a
+++ /dev/null
-Subproject commit 53971fce51da881659a9c3cd6873c2fd357ef129
+++ /dev/null
-Subproject commit 07d4963f56ec994d53a2f3a8e8584f371ede44c7
-Subproject commit 61f3a374264b8e6c6c0d8bce6b05431c77fa7a06
+Subproject commit 8a66c31178c169dda4786f79be5cc5ffe0f94dae
+++ /dev/null
-Subproject commit 202363c68fb42b3731bdc457d58128b82a1fd71d
+++ /dev/null
-Subproject commit cb1d2f74b370c16357af975a136e687fba3303e6
+++ /dev/null
-Subproject commit 761c4442083577cb262f9e8206360ff016e9d9c0
-Subproject commit 947fe149bdc8bf1337c5b8d23faa05d57076f22c
+Subproject commit 51c599a04b50c35685abb751ec00eef5038ffecd
+++ /dev/null
-Subproject commit 107450f59231a570b31059c8cbc79c0cbae25b61
-Subproject commit 8f24202cbd59e400dfb7a8a629bc13e954f90105
+Subproject commit 4d09be5502fea007d02fc2bceaecb103e92a58af
+++ /dev/null
-Subproject commit 051832edc92741112ecc244e68d00f19c7cd33d8
Authorization <http://shiro.apache.org/web.html#Web-%7B%7B%5Curls%5C%7D%7D>`_
describes how to configure the Authentication feature in detail.
-.. notes::
+.. note::
The Shiro-Based Authorization that uses the *shiro.ini* URLs section to
define roles requirements is **deprecated** and **discouraged** since the
<local-discriminator>2000</local-discriminator>
</as-generated>
+**P-Multicast Service Interface Tunnel (PMSI) attribute:**
+
+* **RSVP-TE P2MP LSP**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <rsvp-te-p2mp-lsp>
+ <p2mp-id>1111111111</p2mp-id>
+ <tunnel-id>11111</tunnel-id>
+ <extended-tunnel-id>10.10.10.10</extended-tunnel-id>
+ </rsvp-te-p2mp-lsp>
+ </pmsi-tunnel>
+
+* **mLDP P2MP LSP**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <mldp-p2mp-lsp>
+ <address-family xmlns:x="urn:opendaylight:params:xml:ns:yang:bgp-types">x:ipv4-address-family</address-family>
+ <root-node-address>10.10.10.10</root-node-address>
+ <opaque-value>
+ <opaque-type>111</opaque-type>
+ <opaque-extended-type>11111</opaque-extended-type>
+ <opaque>aa:aa:aa</opaque>
+ </opaque-value>
+ </mldp-p2mp-lsp>
+ </pmsi-tunnel>
+
+* **PIM-SSM Tree**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <pim-ssm-tree>
+ <p-address>11.12.13.14</p-address>
+ <p-multicast-group>10.10.10.10</p-multicast-group>
+ </pim-ssm-tree>
+ </pmsi-tunnel>
+
+* **PIM-SM Tree**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <pim-sm-tree>
+ <p-address>11.12.13.14</p-address>
+ <p-multicast-group>10.10.10.10</p-multicast-group>
+ </pim-sm-tree>
+ </pmsi-tunnel>
+
+* **BIDIR-PIM Tree**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <bidir-pim-tree>
+ <p-address>11.12.13.14</p-address>
+ <p-multicast-group>10.10.10.10</p-multicast-group>
+ </bidir-pim-tree>
+ </pmsi-tunnel>
+
+* **Ingress Replication**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <ingress-replication>
+ <receiving-endpoint-address>172.12.123.3</receiving-endpoint-address>
+ </ingress-replication>
+ </pmsi-tunnel>
+
+* **mLDP MP2MP LSP**
+ .. code-block:: xml
+
+ <pmsi-tunnel>
+ <leaf-information-required>true</leaf-information-required>
+ <mpls-label>20024</mpls-label>
+ <mldp-mp2mp-lsp>
+ <opaque-type>111</opaque-type>
+ <opaque-extended-type>11111</opaque-extended-type>
+ <opaque>aa:aa</opaque>
+ </mldp-mp2mp-lsp>
+ </pmsi-tunnel>
+
**Extended Communities:**
* **ESI Label Extended Community**
<esi-label-extended-community>
<single-active-mode>false</single-active-mode>
<esi-label>24001</esi-label>
- </esi-label-extended-community >
+ </esi-label-extended-community>
</extended-communities>
* **ES-Import Route Target**
@line 4: `full list of tunnel types <http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types>`_
-* **P-Multicast Service Interface Tunnel (PMSI) attribute**
- .. code-block:: xml
-
- <pmsi-tunnel>
- <leaf-information-required>true</leaf-information-required>
- <mpls-label>20024</mpls-label>
- <ingress-replication>
- <receiving-endpoint-address>172.12.123.3</receiving-endpoint-address>
- </ingress-replication>
- </pmsi-tunnel>
-
-----
To remove the route added above, following request can be used:
eman is composed of 3 Karaf features:
* ``eman`` incudes the YANG model and its implementation
* ``eman-api`` adds support for REST
- * ``eman-ui`` adds support for DLUX.
Developers will typically interface with ``eman-api``.
A set of virtual switches (OVS) have to be registered or discovered by
ODL. Mininet is recommended to create a OVS network. After an OVS
network is created, set up the controller IP pointing to ODL IP address
-in each of the OVS. From ODL, a physical topology can be viewed via ODL
-DLUX UI or retrieved via RESTCONF API.
+in each of the OVS. From ODL, a physical topology can be viewed via
+RESTCONF API.
Instructions
^^^^^^^^^^^^
- `the **GBP** demo and development environments for tips <#demo>`__
-It is recommended to use either:
+It is recommended to use:
- `Neutron mapper <gbp-neutron>`
-- :ref:`the UX <gbp-ux>`
-
-If the REST API must be used, and the above resources are not
-sufficient:
-
-- feature:install odl-dluxapps-yangui
-
-- browse to:
- ``http://<odl-controller>:8181/index.html``
- and select YangUI from the left menu.
-
-to explore the various **GBP** REST options
-
.. _gbp-neutron:
Using OpenStack with GBP
:maxdepth: 1
opendaylight-controller-overview
- using-the-opendaylight-user-interface-(dlux)
../getting-started-guide/common-features/clustering.rst
../getting-started-guide/common-features/persistence_and_backup.rst
well as adding mapping information through the Map Server. Key-EID
associations and mappings can also be queried via this API.
-- **GUI:** This module enables adding and querying the mapping service
- through a GUI based on ODL DLUX.
-
- **Neutron:** This module implements the OpenDaylight Neutron Service
APIs. It provides integration between the LISP service and the
OpenDaylight Neutron service, and thus OpenStack.
* NEMO REST
* The NEMO REST provides users REST APIs to access NEMO engine, that is, user could
transmit the intent instance to NEMO engine through basic REST methods.
-* NEMO UI
- * The NEMO UI provides users a visual interface to deploy service with NEMO model,
- and display the state in DLUX UI.
Installing NEMO engine
----------------------
(odl-ocpjava-protocol), provides OpenDaylight with basic OCP v4.1.1
functionality.
-There are two ways to interact with OCP service: one is via RESTCONF
-(programmatic) and the other is using DLUX web interface (manual), so
-you have to install the following features to enable RESTCONF and DLUX.
+You can interact with OCP service via RESTCONF, so you have to install
+the following features to enable RESTCONF.
::
- karaf#>feature:install odl-restconf odl-l2switch-switch odl-mdsal-apidocs odl-dlux-core odl-dluxapps-applications
+ karaf#>feature:install odl-restconf odl-l2switch-switch odl-mdsal-apidocs
Then install the odl-ocpplugin-all feature which includes the
odl-ocpplugin-southbound and odl-ocpplugin-app-ocp-service features.
java -classpath simple-agent-${ocp-version}.jar org.opendaylight.ocpplugin.OcpAgent 127.0.0.1 1033 XYZ 123
-Web / Graphical Interface
--------------------------
-
-Once you enable the DLUX feature, you can access the Controller GUI
-using following URL.
-
-::
-
- http://<controller-ip>:8080/index.html
-
-Expand Nodes. You should see all the radio head devices that are
-connected to the controller running at <controller-ip>.
-
-.. figure:: ./images/ocpplugin/dlux-ocp-nodes.jpg
- :alt: DLUX Nodes
-
- DLUX Nodes
-
-And expand Yang UI if you want to browse the various northbound APIs
-exposed by the OCP service.
-
-.. figure:: ./images/ocpplugin/dlux-ocp-apis.jpg
- :alt: DLUX Yang UI
-
- DLUX Yang UI
-
-For information on how to use these northbound APIs, please refer to the
-OCP Plugin Developer Guide.
-
Programmatic Interface
----------------------
karaf#>feature:install odl-restconf
-If you want to access the Controller GUI, you have to install
-*odl-dlux-core* feature to enable that. Run following command to install
-it
-
-::
-
- karaf#>feature:install odl-dlux-core
-
-Once you enable the feature, access the Controller GUI using following
-URL
-
-::
-
- http://<controller-ip>:8181/dlux/index.html
-
OpenFlow 1.3 Enabled Software Switches / Environment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Overview
~~~~~~~~
-The SFC User interface comes in two flavors:
-
-- Web Interface (SFC-UI): is based on Dlux project. It provides an easy way to
- create, read, update and delete configuration stored in the datastore.
- Moreover, it shows the status of all SFC features (e.g installed,
- uninstalled) and Karaf log messages as well.
-
-- Command Line Interface (CLI): it provides several Karaf console commands to
- show the SFC model (SF, SFFs, etc.) provisioned in the datastore.
+The SFC User interface comes with a Command Line Interface (CLI): it provides
+several Karaf console commands to show the SFC model (SF, SFFs, etc.) provisioned
+in the datastore.
SFC Web Interface (SFC-UI)
--- /dev/null
+.. _tsdr-elasticsearch-user-guide:
+
+ElasticSearch
+=============
+
+Setting Up the environment
+--------------------------
+
+To setup and run the TSDR data store ElasticSearch feature, you need to have
+an ElasticSearch node (or a cluster of such nodes) running. You can use a
+customized ElasticSearch docker image for this purpose.
+
+Your ElasticSearch (ES) setup must have the "Delete By Query Plugin" installed.
+Without this, some of the ES functionality won't work properly.
+
+
+Creating a custom ElasticSearch docker image
+--------------------------------------------
+
+(You can skip this section if you already have an instance of ElasticSearch running)
+
+Run the following set of commands:
+
+ ::
+
+ cat << EOF > Dockerfile
+ FROM elasticsearch:2
+ RUN /usr/share/elasticsearch/bin/plugin install --batch delete-by-query
+ EOF
+
+
+To build the image, run the following command in the directory where the
+Dockerfile was created:
+
+ ::
+
+ docker build . -t elasticsearch-dd
+
+
+You can check whether the image was properly created by running:
+
+ ::
+
+ docker images
+
+
+This should print all your container images including the elasticsearch-dd.
+
+Now we can create and run a container from our image by typing:
+
+ ::
+
+ docker run -d -p 9200:9200 -p 9300:9300 --name elasticsearch-dd elasticsearch-dd
+
+
+To see whether the container is running, run the following command:
+
+ ::
+
+ docker ps
+
+
+The output should include a row with elasticsearch-dd in the NAMES column.
+To check the std out of this container use
+
+ ::
+
+ docker logs elasticsearch-dd
+
+
+Running the ElasticSearch feature
+---------------------------------
+
+Once the features have been installed, you can change some of its properties. For
+example, to setup the URL where your ElasticSearch installation runs,
+change the *serverUrl* parameter in tsdr/persistence-elasticsearch/src/main/resources/configuration/initial/:
+
+ tsdr-persistence-elasticsearch.properties
+
+
+All the data are stored into the TSDR index under a type. The metric data are
+stored under the metric type and the log data are store under the log type.
+You can modify the files in tsdr/persistence-elasticsearch/src/main/resources/configuration/initial/:
+
+ tsdr-persistence-elasticsearch_metric_mapping.json
+ tsdr-persistence-elasticsearch_log_mapping.json
+
+to change or tune the mapping for those types. The changes in those files will be promoted after
+the feature is reloaded or the distribution is restarted.
+
+
+Testing the setup
+^^^^^^^^^^^^^^^^^
+
+We can now test whether the setup is correct by downloading and installing mininet,
+which we use to send some data to the running ElasticSearch instance.
+
+Installing the necessary features:
+
+Start OpenDaylight
+
+ ::
+
+ feature:install odl-restconf odl-l2switch-switch odl-tsdr-core odl-tsdr-openflow-statistics-collector
+ feature:install odl-tsdr-elasticsearch
+
+We can check whether the distribution is now listening on port 6653:
+
+ ::
+
+ netstat -an | grep 6653
+
+Run mininet
+
+ ::
+
+ sudo mn --topo single,3 --controller 'remote,ip=distro_ip,port=6653' --switch ovsk,protocols=OpenFlow13
+
+
+where the distro_ip is the IP address of the machine where the OpenDaylight distribution
+is running. This command will create three hosts connected to one OpenFlow capable
+switch.
+
+We can check if data was stored by ElasticSearch in TSDR by running the
+following command:
+
+ ::
+
+ tsdr:list FLOWTABLESTATS
+
+The output should look similar to the following::
+
+ [NID=openflow:1][DC=FLOWTABLESTATS][MN=ActiveFlows][RK=Node:openflow:1,Table:50][TS=1473427383598][3]
+ [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:50][TS=1473427383598][12]
+ [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketLookup][RK=Node:openflow:1,Table:50][TS=1473427383598][12]
+ [NID=openflow:1][DC=FLOWTABLESTATS][MN=ActiveFlows][RK=Node:openflow:1,Table:80][TS=1473427383598][3]
+ [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:80][TS=1473427383598][17]
+ [NID=openflow:1][DC=FLOWTABLESTATS][MN=PacketMatch][RK=Node:openflow:1,Table:246][TS=1473427383598][19]
+ ...
+
+Or you can query your ElasticSearch instance:
+
+ ::
+
+ curl -XPOST "http://elasticseach_ip:9200/_search?pretty" -d'{ "from": 0, "size": 10000, "query": { "match_all": {} } }'
+
+The elasticseach_ip is the IP address of the server where the ElasticSearch is running.
+
+
+Web Activity Collector
+======================
+
+The Web Activity Collector records the meaningful REST requests made through the
+OpenDaylight RESTCONF interface.
+
+
+How to test the RESTCONF Collector
+----------------------------------
+
+- Install some other feature that has a RESTCONF interface, for example. "odl-tsdr-syslog-collector"
+- Issue a RESTCONF command that uses either POST,PUT or DELETE.
+ For example, you could call the register-filter RPC of tsdr-syslog-collector.
+- Look up data in TSDR database from Karaf.
+
+ ::
+
+ tsdr:list RESTCONF
+
+
+- You should see the request that you have sent, along with its information
+ (URL, HTTP method, requesting IP address and request body)
+- Try to send a GET request, then check again, your request should not be
+ registered, because the collector does not register GET requests by default.
+- Open the file: "etc/tsdr.restconf.collector.cfg", and add GET to the list of
+ METHODS_TO_LOG, so that it becomes:
+
+
+ METHODS_TO_LOG=POST,PUT,DELETE,GET
+
+ - Try again to issue your GET request, and check if it was recorded this time,
+ it should be recorder.
+ - Try manipulating the other properties (PATHS_TO_LOG (which URLs do we want
+ to log from), REMOTE_ADDRESSES_TO_LOG (which requesting IP addresses do we
+ want to log from) and CONTENT_TO_LOG (what should be in the request's body
+ in order to log it)), and see if the requests are getting logged.
+ - Try providing invalid properties (unknown methods for the METHODS_TO_LOG
+ parameter, or the same method repeated multiple times, and invalid regular
+ expressions for the other parameters), then check karaf's log using
+ "log:display". It should tell you that the value is invalid, and that it
+ will use the default value instead.
+
--- /dev/null
+.. _tsdr-hbase-user-guide:
+
+TSDR HBase Data Store User Guide
+================================
+
+This document describes how to use HBase to capture time series data
+using Time Series Data Repository (TSDR) feature in the OpenDaylight
+Lithium release. This document contains configuration, administration,
+management, usage, and troubleshooting sections for the feature.
+
+Overview
+--------
+
+The Time Series Data Repository (TSDR) project in OpenDaylight (ODL) creates a framework for collecting, storing, querying, and maintaining time series data in then OpenDaylight SDN controller. TSDR provides the framework for plugging in proper data collectors to collect various time series data and store into TSDR data stores. With a common data model and generic TSDR data persistence APIs, the user could choose various data stores to be plugged into TSDR Persistence framework. In Lithium, two types of data stores are supported: HBase NoSQL database and H2 relational database.
+
+With the capabilities of data collection, storage, query, aggregation, and purging provided by TSDR, network administrators could leverage various data driven appliations built on top of TSDR for security risk detection, performance analysis, operational configuration optimization, traffic engineering, and network analytics with automated intelligence.
+
+TSDR with HBase Data Store Architecture
+---------------------------------------
+
+TSDR contains the following services and components
+
+- Data Collection Service
+- Data Storage Service
+- TSDR Persistence Layer with data stores as plugins
+- TSDR Data Stores
+- Data Query Service
+- Data Aggregation Service
+- Data Purging Service
+
+Data Collection Service handles the collection of time series data into TSDR and hands it over to Data Storage Service. Data Storage Service stores the data into TSDR through TSDR Persistence Layer. TSDR Persistence Layer provides generic Service APIs allowing various data stores to be plugged in. Data Aggregation Service aggregates time series fine-grained raw data into course-grained roll-up data to control the size of the data. Data Purging Service periodically purges both fine-grained raw data and course-granined aggregated data according to user-defined schedules.
+
+
+In Lithium, we implemented Data Collection Service, Data Storage Service, TSDR Persistence Layer, TSDR HBase Data Store, and TSDR H2 Data Store. Among these services and components, time series data is communicated using a common TSDR data model, which is designed and implemented for the abstraction of time series data commonalities. With these functions, TSDR will be able to collect the data from the data sources and store them into one of the TSDR data stores: either HBase Data Store or H2 Data Store. We also provided a simple query command from Karaf console for the user to retrieve TSDR data from the data stores.
+
+
+A future release will contain Data Aggregation service, Data Purging Service, and a full-fledged Data Query Service with Norghbound APIs.
+
+Configuring TSDR with HBase Data Store
+--------------------------------------
+
+After installing HBase Server on the same VM as the OpenDaylight Controller, if the user accepts the default configuration of the HBase Data Store, the user can directly proceed with the installation of HBase Data Store from Karaf console.
+
+Optionally, the user can configure TSDR HBase Data Store following HBase Data Store Configuration Procedure.
+
+HBase Data Store Configuration Steps
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+- Open the file etc/tsdr-persistence-hbase.peroperties under karaf distribution directory.
+- Edit the following parameters
+ - HBase server name
+ - HBase server port
+ - HBase client connection pool size
+ - HBase client write buffer size
+
+After the configuration of HBase Data Store is complete, proceed with the installation of HBase Data Store from Karaf console.
+
+- HBase Data Store Installation Steps
+ - Start Karaf Console
+ - Run the following commands from Karaf Console:
+
+ ::
+
+ feature:install odl-tsdr-hbase
+
+
+Administering or Managing TSDR HBase Data Store
+-----------------------------------------------
+
+Using Karaf Command to retrieve data from HBase Data Store
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The user can retrieve the data from HBase data store using the following commands from Karaf console:
+
+ ::
+
+ tsdr:list
+
+ ::
+
+ tsdr:list <CategoryName> <StartTime> <EndTime>
+
+Typing tab will get the context prompt of the arguments when typeing the command in Karaf console.
+
+Troubleshooting issues with log files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+- Karaf logs
+
+Similar to other OpenDaylight components and features, TSDR HBase Data Store writes logging information to Karaf logs. All the information messages, warnings, error messages, and debug messages are written to Karaf logs.
+
+- HBase logs
+
+For HBase system level logs, the user can check standard HBase server logs, which is under <HBase-installation-directory>/logs.
+
+Tutorials
+=========
+
+How to use TSDR to collect, store, and view OpenFlow Interface Statistics
+
+Overview
+--------
+
+This tutorial describes an example of using TSDR to collect, store, and view one type of time series data in OpenDaylight environment.
+
+
+Prerequisites
+-------------
+
+You would need to have the following as prerequisits:
+ - One or multiple OpenFlow enabled switches. Alternatively, you can use mininet to simulate such a switch.
+ - Successfully installed OpenDaylight Controller.
+ - Successfully installed HBase Data Store following TSDR HBase Data Store Installation Guide.
+ - Connect the OpenFlow enabled switch(es) to OpenDaylight Controller.
+
+Target Environment
+------------------
+
+HBase data store is only supported in Linux operation system.
+
+Instructions
+------------
+
+- Start OpenDaylight controller.
+
+- Connect OpenFlow enabled switch(es) to the controller. If using mininet, run the following commands from mininet command line:
+
+ ::
+
+ mn --topo single,3 --controller 'remote,ip=172.17.252.210,port=6653' --switch ovsk,protocols=OpenFlow13
+
+- If using real switch(es), the OpenDaylight controller should be able to discover the network toplogy containing the switches.
+
+- Install tsdr hbase feature from Karaf:
+
+ ::
+
+ feature:install odl-tsdr-hbase
+
+- run the following command from Karaf console:
+
+ ::
+
+ tsdr:list InterfaceStats
+
+You should be able to see the interface statistics of the switch(es) from the HBase Data Store. If there are too many rows, you can use "tsdr:list InterfaceStats|more" to view it page by page.
+
+By tabbing after "tsdr:list", you will see all the supported data categories. For example, "tsdr:list FlowStats" will output the Flow statistics data collected from the switch(es).
+
--- /dev/null
+.. _tsdr-hsqldb-user-guide:
+
+TSDR HSQLDB Datastore User Guide
+================================
+
+This document describes how to use the embedded datastore HSQLDB, which is the default datastore (recommended for non-production use case) introduced as part of OpenDaylight Time Series Data Respository (TSDR) project. This store captures the time series data. This document contains configuration, administration, management, using, and troubleshooting sections for the feature.
+
+Overview
+--------
+
+In the Lithium Release of Time Series Data Repository (TSDR), time series metrics corresponding to the OpenFlow statistics are captured. For users trying out things on their laptop or non-production environment, TSDR functionality can be enabled with default datastore HSQLDB by installing the feature odl-tsdr-all.
+
+TSDR Architecture
+-----------------
+
+The following wiki pages capture the TSDR Model/Architecture
+
+a. https://wiki.opendaylight.org/view/TSDR_Data_Storage_Service_and_Persistence_with_HBase_Plugin
+b. https://wiki.opendaylight.org/view/TSDR_Data_Collection_Service
+
+Note in Lithium the DataCollection Service is implemented just for OpenFlow Statistics metrics.
+
+Administering or Managing TSDR with default datastore HSQLDB
+------------------------------------------------------------
+
+Once the TSDR default datastore feature (odl-tsdr-all) is enabled, the TSDR captured OpenFlow statistics metrics can be accessed from Karaf Console by executing the command
+
+ ::
+
+ tsdr:list <metric-category> <starttimestamp> <endtimestamp>
+
+wherein
+
+ ::
+
+ <metric-category> = any one of the following categories FlowGroupStats, FlowMeterStats, FlowStats, FlowTableStats, PortStats, QueueStats
+ <starttimestamp> = to filter the list of metrics starting this timestamp
+ <endtimestamp> = to filter the list of metrics ending this timestamp
+
+If either of <starttimestamp> or <endtimestamp> is not specified, this command displays the latest 1000 metrics captured.
+
- Start Karaf Console
- - Run the following commands from Karaf Console: feature:install
- odl-tsdr-hbase
+ - Run the following commands from Karaf Console:
+
+ ::
+
+ feature:install odl-tsdr-hbase
To Configure Cassandra Data Store
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
enabled, the TSDR captured OpenFlow statistics metrics can be accessed
from Karaf Console by executing the command
-::
+ ::
- tsdr:list <metric-category> <starttimestamp> <endtimestamp>
+ tsdr:list <metric-category> <starttimestamp> <endtimestamp>
wherein
To Administer HBase Data Store
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Using Karaf Command to retrieve data from HBase Data Store
+Using Karaf Command to retrieve data from HBase Data Store
The user first need to install hbase data store from karaf console:
-feature:install odl-tsdr-hbase
+ ::
+
+ feature:install odl-tsdr-hbase
The user can retrieve the data from HBase data store using the following
commands from Karaf console:
-::
+ ::
- tsdr:list
- tsdr:list <CategoryName> <StartTime> <EndTime>
+ tsdr:list
+
+ ::
+
+ tsdr:list <CategoryName> <StartTime> <EndTime>
Typing tab will get the context prompt of the arguments when typeing the
command in Karaf console.
The user first needs to install Cassandra data store from Karaf console:
-::
+ ::
- feature:install odl-tsdr-cassandra
+ feature:install odl-tsdr-cassandra
Then the user can retrieve the data from Cassandra data store using the
following commands from Karaf console:
-::
+ ::
+
+ tsdr:list
- tsdr:list
- tsdr:list <CategoryName> <StartTime> <EndTime>
+ ::
+
+ tsdr:list <CategoryName> <StartTime> <EndTime>
Typing tab will get the context prompt of the arguments when typeing the
command in Karaf console.
feature:install odl-tsdr-netflow-statistics-collector
-- sFlow Data Collector
+- Syslog Data Collector
::
- feature:install odl-tsdr-sflow-statistics-colletor
+ feature:install odl-tsdr-syslog-collector
-- SNMP Data Collector
+- Controller Metrics Collector
::
- feature:install odl-tsdr-snmp-data-collector
+ feature:install odl-tsdr-controller-metrics-collector
-- Syslog Data Collector
+- Web Activity Collector
::
- feature:install odl-tsdr-syslog-collector
+ feature:install odl-tsdr-restconf-collector
-- Controller Metrics Collector
+- sFlow Data Collector (experimental)
::
- feature:install odl-tsdr-controller-metrics-collector
+ feature:install odl-tsdr-sflow-statistics-colletor
-- Web Activity Collector
+- SNMP Data Collector (experimental)
::
- feature:install odl-tsdr-restconf-collector
+ feature:install odl-tsdr-snmp-data-collector
In order to use controller metrics collector, the user needs to install
directory in your controller home directory and place the
"sigar-1.6.4.jar" there
+
+Querying TSDR from REST APIs
+----------------------------
+
+TSDR provides two REST APIs for querying data stored in TSDR data
+stores.
+
+- Query of TSDR Metrics
+
+ - URL: http://localhost:8181/tsdr/metrics/query
+
+ - Verb: GET
+
+ - Parameters:
+
+ - tsdrkey=[NID=][DC=][MN=][RK=]
+
+ ::
+
+ The TSDRKey format indicates the NodeID(NID), DataCategory(DC), MetricName(MN), and RecordKey(RK) of the monitored objects.
+ For example, the following is a valid tsdrkey:
+ [NID=openflow:1][DC=FLOWSTATS][MN=PacketCount][RK=Node:openflow:1,Table:0,Flow:3]
+ The following is also a valid tsdrkey:
+ tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]
+ In the case when the sections in the tsdrkey is empty, the query will return all the records in the TSDR data store that matches the filled tsdrkey. In the above example, the query will return all the data in FLOWSTATS data category.
+ The query will return only the first 1000 records that match the query criteria.
+
+ - from=<time\_in\_seconds>
+
+ - until=<time\_in\_seconds>
+
+The following is an example curl command for querying metric data from
+TSDR data store:
+
+ ::
+
+ curl -G -v -H "Accept: application/json" -H "Content-Type:
+ application/json" "http://localhost:8181/tsdr/metrics/query"
+ --data-urlencode "tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]"
+ --data-urlencode "from=0" --data-urlencode "until=240000000000"\|more
+
+- Query of TSDR Log type of data
+
+ - URL:http://localhost:8181/tsdr/logs/query
+
+ - Verb: GET
+
+ - Parameters:
+
+ - tsdrkey=tsdrkey=[NID=][DC=][RK=]
+
+ - The TSDRKey format indicates the NodeID(NID), DataCategory(DC), and RecordKey(RK) of the monitored objects.
+ For example, the following is a valid tsdrkey:
+ [NID=openflow:1][DC=NETFLOW][RK]
+ The query will return only the first 1000 records that match the query criteria.
+
+ - from=<time\_in\_seconds>
+
+ - until=<time\_in\_seconds>
+
+The following is an example curl command for querying log type of data
+from TSDR data store:
+
+ ::
+
+ curl -G -v -H "Accept: application/json" -H "Content-Type: application/json" "http://localhost:8181/tsdr/logs/query"
+ --data-urlencode "tsdrkey=[NID=][DC=NETFLOW][RK=]" --data-urlencode
+ "from=0" --data-urlencode "until=240000000000"\|more
+
+Grafana integration with TSDR
+-----------------------------
+
+TSDR provides northbound integration with Grafana time series data
+visualization tool. All the metric type of data stored in TSDR data
+store can be visualized using Grafana.
+
+For the detailed instruction about how to install and configure Grafana
+to work with TSDR, please refer to the following link:
+
+https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step
+
Configuring TSDR Data Collectors
--------------------------------
-- SNMP Data Collector Device Credential Configuration
+SNMP Data Collector Device Credential Configuration (experimental)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After installing SNMP Data Collector, a configuration file under etc/
directory of ODL distribution is generated: etc/tsdr.snmp.cfg is
}
}
-Querying TSDR from REST APIs
-----------------------------
-
-TSDR provides two REST APIs for querying data stored in TSDR data
-stores.
-
-- Query of TSDR Metrics
-
- - URL: http://localhost:8181/tsdr/metrics/query
-
- - Verb: GET
-
- - Parameters:
-
- - tsdrkey=[NID=][DC=][MN=][RK=]
-
- ::
-
- The TSDRKey format indicates the NodeID(NID), DataCategory(DC), MetricName(MN), and RecordKey(RK) of the monitored objects.
- For example, the following is a valid tsdrkey:
- [NID=openflow:1][DC=FLOWSTATS][MN=PacketCount][RK=Node:openflow:1,Table:0,Flow:3]
- The following is also a valid tsdrkey:
- tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]
- In the case when the sections in the tsdrkey is empty, the query will return all the records in the TSDR data store that matches the filled tsdrkey. In the above example, the query will return all the data in FLOWSTATS data category.
- The query will return only the first 1000 records that match the query criteria.
-
- - from=<time\_in\_seconds>
-
- - until=<time\_in\_seconds>
-
-The following is an example curl command for querying metric data from
-TSDR data store:
-
-curl -G -v -H "Accept: application/json" -H "Content-Type:
-application/json" "http://localhost:8181/tsdr/metrics/query"
---data-urlencode "tsdrkey=[NID=][DC=FLOWSTATS][MN=][RK=]"
---data-urlencode "from=0" --data-urlencode "until=240000000000"\|more
-
-- Query of TSDR Log type of data
-
- - URL:http://localhost:8181/tsdr/logs/query
-
- - Verb: GET
-
- - Parameters:
-
- - tsdrkey=tsdrkey=[NID=][DC=][RK=]
-
- ::
-
- The TSDRKey format indicates the NodeID(NID), DataCategory(DC), and RecordKey(RK) of the monitored objects.
- For example, the following is a valid tsdrkey:
- [NID=openflow:1][DC=NETFLOW][RK]
- The query will return only the first 1000 records that match the query criteria.
-
- - from=<time\_in\_seconds>
-
- - until=<time\_in\_seconds>
-
-The following is an example curl command for querying log type of data
-from TSDR data store:
-
-curl -G -v -H "Accept: application/json" -H "Content-Type:
-application/json" "http://localhost:8181/tsdr/logs/query"
---data-urlencode "tsdrkey=[NID=][DC=NETFLOW][RK=]" --data-urlencode
-"from=0" --data-urlencode "until=240000000000"\|more
-
-Grafana integration with TSDR
------------------------------
-
-TSDR provides northbound integration with Grafana time series data
-visualization tool. All the metric type of data stored in TSDR data
-store can be visualized using Grafana.
-
-For the detailed instruction about how to install and configure Grafana
-to work with TSDR, please refer to the following link:
-
-https://wiki.opendaylight.org/view/Grafana_Integration_with_TSDR_Step-by-Step
-
Purging Service configuration
-----------------------------
- If using mininet, run the following commands from mininet command
line:
- - mn --topo single,3 --controller
- *remote,ip=172.17.252.210,port=6653* --switch
- ovsk,protocols=OpenFlow13
+ ::
+
+ mn --topo single,3 --controller *remote,ip=172.17.252.210,port=6653* --switch
+ ovsk,protocols=OpenFlow13
- Install TSDR hbase feature from Karaf:
- - feature:install odl-tsdr-hbase
+ ::
+
+ feature:install odl-tsdr-hbase
- Install OpenFlow Statistics Collector from Karaf:
- - feature:install odl-tsdr-openflow-statistics-collector
+ ::
+
+ feature:install odl-tsdr-openflow-statistics-collector
- run the following command from Karaf console:
- - tsdr:list PORTSTATS
+ ::
+
+ tsdr:list PORTSTATS
You should be able to see the interface statistics of the switch(es)
from the HBase Data Store. If there are too many rows, you can use
statistics data collected from the switch(es).
-.. include:: tsdr-elastic-search.rst
-
-
Troubleshooting
---------------
(TLS) since the OpenFlow Plugin that TSDR depends on provides this
security support.
-- SNMP Security
-
- - The SNMP version3 has security support. However, since ODL SNMP
- Plugin that TSDR depends on does not support version 3, we (TSDR)
- will not have security support at this moment.
-
- NetFlow Security
- NetFlow, which cannot be configured with security so we recommend
- Syslog, which cannot be configured with security so we recommend
making sure it flows only over a secured management network.
+- SNMP Security
+
+ - The SNMP version3 has security support. However, since ODL SNMP
+ Plugin that TSDR depends on does not support version 3, we (TSDR)
+ will not have security support at this moment.
+
+- sFlow Security
+
+ - The sflow has security support.
+
+
Support multiple data stores simultaneously at runtime
------------------------------------------------------
example, the default content of tsdr-persistence-hsqldb.properties is as
follows:
-::
+ ::
- metric-persistency=true
- log-persistency=true
- binary-persistency=true
+ metric-persistency=true
+ log-persistency=true
+ binary-persistency=true
When the user would like to use different data stores to support
different types of data, he/she could enable or disable a particular
metric-psersistency=true
log-persistency=false
binary-persistency=false
+
- The USC Manager handles configurations, high availability,
security, monitoring, and clustering support for USC.
-- USC UI
-
- - The USC UI is responsible for displaying a graphical user
- interface representing the state of USC in the OpenDaylight DLUX
- UI.
-
Installing USC Channel
----------------------
+++ /dev/null
-Using the OpenDaylight User Interface (DLUX)
-============================================
-
-This section introduces you to the OpenDaylight User Experience (DLUX)
-application.
-
-Getting Started with DLUX
--------------------------
-
-DLUX provides a number of different Karaf features, which you can enable
-and disable separately. They are:
-
- - odl-dlux-core
- - odl-dluxapps-nodes
- - odl-dluxapps-topology
- - odl-dluxapps-yangui
- - odl-dluxapps-yangvisualizer
- - odl-dluxapps-yangman
-
-Logging In
-----------
-
-To log in to DLUX, after installing the application:
-
-1. Open a browser and enter the login URL
- http://<your-karaf-ip>:8181/index.html
- in your browser (Chrome is recommended).
-
-2. Login to the application with your username and password credentials.
-
-.. note::
-
- OpenDaylight’s default credentials are *admin* for both the username
- and password.
-
-Working with DLUX
------------------
-
-After you login to DLUX, if you enable only odl-dlux-core feature, you
-will see only topology application available in the left pane.
-
-.. note::
-
- To make sure topology displays all the details, enable the
- odl-l2switch-switch feature in Karaf.
-
-DLUX has other applications such as node, yang UI and those apps won’t
-show up, until you enable their features odl-dluxapps-nodes and
-odl-dluxapps-yangui respectively in the Karaf distribution.
-
-.. figure:: ./images/dlux-login.png
- :alt: DLUX Modules
-
- DLUX Modules
-
-.. note::
-
- If you install your application in dlux, they will also show up on
- the left hand navigation after browser page refresh.
-
-Viewing Network Statistics
---------------------------
-
-The **Nodes** module on the left pane enables you to view the network
-statistics and port information for the switches in the network.
-
-To use the **Nodes** module:
-
-1. Select **Nodes** on the left pane. The right pane displays atable
- that lists all the nodes, node connectors and the statistics.
-
-2. Enter a node ID in the **Search Nodes** tab to search by node
- connectors.
-
-3. Click on the **Node Connector** number to view details such as port
- ID, port name, number of ports per switch, MAC Address, and so on.
-
-4. Click **Flows** in the Statistics column to view Flow Table
- Statistics for the particular node like table ID, packet match,
- active flows and so on.
-
-5. Click **Node Connectors** to view Node Connector Statistics for the
- particular node ID.
-
-Viewing Network Topology
-------------------------
-
-The Topology tab displays a graphical representation of network topology
-created.
-
-.. note::
-
- DLUX does not allow for editing or adding topology information. The
- topology is generated and edited in other modules, e.g., the
- OpenFlow plugin. OpenDaylight stores this information in the MD-SAL
- datastore where DLUX can read and display it.
-
-To view network topology:
-
-1. Select **Topology** on the left pane. You will view the graphical
- representation on the right pane. In the diagram blue boxes represent
- the switches, the black represents the hosts available, and lines
- represents how the switches and hosts are connected.
-
-2. Hover your mouse on hosts, links, or switches to view source and
- destination ports.
-
-3. Zoom in and zoom out using mouse scroll to verify topology for larger
- topologies.
-
-.. figure:: ./images/dlux-topology.png
- :alt: Topology Module
-
- Topology Module
-
-Interacting with the YANG-based MD-SAL datastore
-------------------------------------------------
-
-The **Yang UI** module enables you to interact with the YANG-based
-MD-SAL datastore. For more information about YANG and how it interacts
-with the MD-SAL datastore, see the *Controller* and *YANG Tools* section
-of the *OpenDaylight Developer Guide*.
-
-.. figure:: ./images/dlux-yang-ui-screen.png
- :alt: Yang UI
-
- Yang UI
-
-To use Yang UI:
-
-1. Select **Yang UI** on the left pane. The right pane is divided in two
- parts.
-
-2. The top part displays a tree of APIs, subAPIs, and buttons to call
- possible functions (GET, POST, PUT, and DELETE).
-
- .. note::
-
- every subAPI can call every function. For example, subAPIs in
- the *operational* store have GET functionality only.
-
- Inputs can be filled from OpenDaylight when existing data from
- OpenDaylight is displayed or can be filled by user on the page and
- sent to OpenDaylight.
-
- Buttons under the API tree are variable. It depends on subAPI
- specifications. Common buttons are:
-
- - GET to get data from OpenDaylight,
-
- - PUT and POST for sending data to OpenDaylight for saving
-
- - DELETE for sending data to OpenDaylight for deleting.
-
- You must specify the xpath for all these operations. This path is
- displayed in the same row before buttons and it may include text
- inputs for specific path element identifiers.
-
- .. figure:: ./images/dlux-yang-api-specification.png
- :alt: Yang API Specification
-
- Yang API Specification
-
-3. The bottom part of the right pane displays inputs according to the
- chosen subAPI.
-
- - Lists are handled as a special case. For example, a device can
- store multiple flows. In this case "flow" is name of the list and
- every list element is identified by a unique key value. Elements
- of a list can, in turn, contain other lists.
-
- - In Yang UI, each list element is rendered with the name of the
- list it belongs to, its key, its value, and a button for removing
- it from the list.
-
- .. figure:: ./images/dlux-yang-sub-api-screen.png
- :alt: Yang UI API Specification
-
- Yang UI API Specification
-
-4. After filling in the relevant inputs, click the **Show Preview**
- button under the API tree to display request that will be sent to
- OpenDaylight. A pane is displayed on the right side with text of
- request when some input is filled.
-
-Displaying Topology on the **Yang UI**
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-To display topology:
-
-1. Select subAPI network-topology <topology revision number> == >
- operational == > network-topology.
-
-2. Get data from OpenDaylight by clicking on the "GET" button.
-
-3. Click **Display Topology**.
-
-.. figure:: ./images/dlux-yang-topology.png
- :alt: DLUX Yang Topology
-
- DLUX Yang Topology
-
-Configuring List Elements on the **Yang UI**
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Lists in Yang UI are displayed as trees. To expand or collapse a list,
-click the arrow before name of the list. To configure list elements in
-Yang UI:
-
-1. To add a new list element with empty inputs use the plus icon-button
- **+** that is provided after list name.
-
-2. To remove several list elements, use the **X** button that is
- provided after every list element.
-
- .. figure:: ./images/dlux-yang-list-elements.png
- :alt: DLUX List Elements
-
- DLUX List Elements
-
-3. In the YANG-based data store all elements of a list must have a
- unique key. If you try to assign two or more elements the same key, a
- warning icon **!** is displayed near their name buttons.
-
- .. figure:: ./images/dlux-yang-list-warning.png
- :alt: DLUX List Warnings
-
- DLUX List Warnings
-
-4. When the list contains at least one list element, after the **+**
- icon, there are buttons to select each individual list element. You
- can choose one of them by clicking on it. In addition, to the right
- of the list name, there is a button which will display a vertically
- scrollable pane with all the list elements.
-
- .. figure:: ./images/dlux-yang-list-button1.png
- :alt: DLUX List Button1
-
- DLUX List Button1
-
Additional Verifications
^^^^^^^^^^^^^^^^^^^^^^^^
-
-- Please visit the OpenDaylight DLUX GUI after stacking all the nodes,
- http://<ODL\_IP\_ADDRESS>:8181/index.html.
- The switches, topology and the ports that are currently read can be
- validated.
-
-::
-
- http://<controller-ip>:8181/index.html
-
-.. tip::
-
- If the interconnected between the Open vSwitch is not seen, Please
- bring up the interface for the dataplane manually using the below
- comamnd
-
::
ifup <interface_name>
- Use *sudo ovs-vsctl show* to list the number of interfaces added.
-- Please visit the DLUX GUI to list the new nodes in every switch.
-
-Getting started with DLUX
-^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Ensure that you have created a topology and enabled MD-SAL feature in
-the Karaf distribution before you use DLUX for network management.
-
-Logging In
-^^^^^^^^^^
-
-To log in to DLUX, after installing the application: \* Open a browser
-and enter the login URL. If you have installed DLUX as a stand-alone,
-then the login URL is http://localhost:9000/DLUX/index.html. However if
-you have deployed DLUX with Karaf, then the login URL is
-http://<your IP>:8181/dlux/index.html. \* Login
-to the application with user ID and password credentials as admin.
-NOTE:admin is the only user type available for DLUX in this release.
-
-Working with DLUX
-^^^^^^^^^^^^^^^^^
-
-To get a complete DLUX feature list, install restconf, odl l2 switch,
-and switch while you start the DLUX distribution.
-
-.. figure:: ./images/vtn/Dlux_login.png
- :alt: DLUX\_GUI
-
- DLUX\_GUI
-
-.. note::
-
- DLUX enables only those modules, whose APIs are responding. If you
- enable just the MD-SAL in beginning and then start dlux, only MD-SAL
- related tabs will be visible. While using the GUI if you enable
- AD-SAL karaf features, those tabs will appear automatically.
-
-Viewing Network Statistics
-^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The Nodes module on the left pane enables you to view the network
-statistics and port information for the switches in the network. \* To
-use the Nodes module: \*\* Select Nodeson the left pane.
-
-::
-
- The right pane displays atable that lists all the nodes, node connectors and the statistics.
-
-- Enter a node ID in the Search Nodes tab to search by node connectors.
-
-- Click on the Node Connector number to view details such as port ID,
- port name, number of ports per switch, MAC Address, and so on.
-
-- Click Flows in the Statistics column to view Flow Table Statistics
- for the particular node like table ID, packet match, active flows and
- so on.
-
-- Click Node Connectors to view Node Connector Statistics for the
- particular node ID.
-
-Viewing Network Topology
-^^^^^^^^^^^^^^^^^^^^^^^^
-
-To view network topology: \* Select Topology on the left pane. You will
-view the graphical representation on the right pane.
-
-::
-
- In the diagram
- blue boxes represent the switches,black represents the hosts available, and lines represents how switches are connected.
-
-.. note::
-
- DLUX UI does not provide ability to add topology information. The
- Topology should be created using an open flow plugin. Controller
- stores this information in the database and displays on the DLUX
- page, when the you connect to the controller using OpenFlow.
-
-.. figure:: ./images/vtn/Dlux_topology.png
- :alt: Topology
-
- Topology
-
OpenStack PackStack Installation Steps
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Code Review / docs.git / commitdiff
