Merge "Add MD-SAL M1 readout"
authorThanh Ha <thanh.ha@linuxfoundation.org>
Mon, 4 Dec 2017 22:11:33 +0000 (22:11 +0000)
committerGerrit Code Review <gerrit@opendaylight.org>
Mon, 4 Dec 2017 22:11:33 +0000 (22:11 +0000)
53 files changed:
.coafile
.gitmodules
docs/developer-guide/index.rst
docs/developer-guide/integrating-animal-sniffer-plugin-with-projects.rst [new file with mode: 0644]
docs/getting-started-guide/common-features/version.rst
docs/getting-started-guide/common-features/xsql.rst [deleted file]
docs/getting-started-guide/security_considerations.rst
docs/index.rst
docs/release-notes/index.rst
docs/release-notes/projects/infrautils.rst
docs/release-process/milestone-readouts/m1/dlux.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m1/dluxapps.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m1/faas.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m1/opflex.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m1/snmp.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m1/tsdr.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/alto.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/bgpcep.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/coe.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/genius.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/groupbasedpolicy.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/honeycomb-vbd.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/infrautils.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/l2switch.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/nemo.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/netvirt.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/neutron-northbound.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/opflex.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/packetcable.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/sfc.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/sxp.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/tsdr.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/usc.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2/vtn.rst [new file with mode: 0644]
docs/release-process/milestone-readouts/m2_template.rst
docs/submodules/aaa
docs/submodules/bgpcep
docs/submodules/coe
docs/submodules/genius
docs/submodules/infrautils
docs/submodules/integration/packaging
docs/submodules/integration/test
docs/submodules/netconf
docs/submodules/netvirt
docs/submodules/odlparent
docs/submodules/openflowplugin [new submodule]
docs/submodules/ovsdb
docs/submodules/releng/builder
docs/submodules/sfc
docs/user-guide/bgp-monitoring-protocol-user-guide.rst
docs/user-guide/bgp-user-guide.rst
docs/user-guide/index.rst
docs/user-guide/p4plugin-user-guide.rst [new file with mode: 0644]

index a60e551ec1a2213477a15c1d33afe04f7f09e8ca..4dfcaca79755f496f7726813400974187d709e49 100644 (file)
--- a/.coafile
+++ b/.coafile
@@ -36,6 +36,7 @@ ignore = .**,
     docs/submodules/netconf/**,
     docs/submodules/netvirt/**,
     docs/submodules/odlparent/**,
+    docs/submodules/openflowplugin/**,
     docs/submodules/ovsdb/**,
     docs/submodules/releng/**,
     docs/submodules/sfc/**,
index c9f26c4075ca6f6d2f422a8890ef3570aa43eaa7..3decda865ed31b34751d5c69f2a48079abce2a53 100644 (file)
@@ -72,3 +72,8 @@
        url = ../sfc
        branch = .
        ignore = dirty
+[submodule "docs/submodules/openflowplugin"]
+       path = docs/submodules/openflowplugin
+       url = ../openflowplugin
+       branch = .
+       ignore = dirty
\ No newline at end of file
index 85eade03eaa629940b1418039453a70ffd66bc0e..73e99bb83938a2b9de4ddb64d7e275cdbf0a980d 100644 (file)
@@ -10,6 +10,7 @@ Overview
 
    ../gerrit
    developing-apps-on-the-opendaylight-controller
+   integrating-animal-sniffer-plugin-with-projects
 
 Project-specific Developer Guides
 ---------------------------------
diff --git a/docs/developer-guide/integrating-animal-sniffer-plugin-with-projects.rst b/docs/developer-guide/integrating-animal-sniffer-plugin-with-projects.rst
new file mode 100644 (file)
index 0000000..cdd5148
--- /dev/null
@@ -0,0 +1,96 @@
+Integrating Animal Sniffer with OpenDaylight projects
+=====================================================
+
+This section provides information required to setup OpenDaylight projects with
+the Maven's `Animal Sniffer plugin`_ for testing API compatibility with OpenJDK.
+
+
+Steps to setup up animal sniffer plugin with your project
+---------------------------------------------------------
+
+1. Clone odlparent and checkout the required branch. The example below uses
+   the branch 'origin/master/2.0.x'
+
+.. code:: shell
+
+    git clone https://git.opendaylight.org/gerrit/odlparent
+    cd odlparent
+    git checkout origin/master/2.0.x
+
+2. Modify the file `odlparent/pom.xml` to install the `Animal Sniffer plugin`_ as
+   shown in the below example or refer to the change `odlparent gerrit patch`_.
+
+.. code:: xml
+
+    <plugin>
+      <groupId>org.codehaus.mojo</groupId>
+      <artifactId>animal-sniffer-maven-plugin</artifactId>
+      <version>1.16</version>
+      <configuration>
+          <signature>
+              <groupId>org.codehaus.mojo.signature</groupId>
+              <artifactId>java18</artifactId>
+              <version>1.0</version>
+          </signature>
+      </configuration>
+      <executions>
+          <execution>
+              <id>animal-sniffer</id>
+              <phase>verify</phase>
+              <goals>
+                  <goal>check</goal>
+              </goals>
+          </execution>
+          <execution>
+              <id>check-java-version</id>
+              <phase>package</phase>
+              <goals>
+                  <goal>build</goal>
+              </goals>
+              <configuration>
+                <signature>
+                  <groupId>org.codehaus.mojo.signature</groupId>
+                  <artifactId>java18</artifactId>
+                  <version>1.0</version>
+                </signature>
+              </configuration>
+          </execution>
+      </executions>
+    </plugin>
+
+3. Run a `mvn clean install` in odlparent.
+
+.. code:: shell
+
+    mvn clean install
+
+4. Clone the respective project to be tested with the plugin. As shown in the
+   example in `yangtools gerrit patch`_, modify the relevant pom.xml files to
+   reference the version of odlparent which is checked-out. As shown in the example
+   below change the version to `2.0.6-SNAPSHOT` or the version of the
+   `2.0.x-SNAPSHOT` odlparent is checked out.
+
+.. code::
+
+    <parent>
+        <groupId>org.opendaylight.odlparent</groupId>
+        <artifactId>odlparent</artifactId>
+        <version>2.0.6-SNAPSHOT</version>
+        <relativePath/>
+    </parent>
+
+5. Run a `mvn clean install` in your project.
+
+.. code:: shell
+
+    mvn clean install
+
+6. Run `mvn animal-sniffer:check` on your project and fix any relevant issues.
+
+.. code:: shell
+
+    mvn animal-sniffer:check
+
+.. _odlparent gerrit patch: https://git.opendaylight.org/gerrit/#/c/64688/
+.. _yangtools gerrit patch: https://git.opendaylight.org/gerrit/64781
+.. _Animal Sniffer plugin: http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/examples/checking-signatures.html
index 4b32d7bb5de000a9013ea698c2363ca091ee9b79..d0085a7839f3d4dcdd60950e1aa3cdff8210fcb3 100644 (file)
@@ -21,8 +21,7 @@ Follow these steps to install the version feature:
 
       feature:install odl-distribution-version
 
-.. note:: For RESTCONF access, it is recommended to install odl-restconf
-          and odl-netconf-connector-ssh.
+.. note:: For RESTCONF access, it is recommended to install odl-restconf.
 
 Version Feature Usage
 ---------------------
diff --git a/docs/getting-started-guide/common-features/xsql.rst b/docs/getting-started-guide/common-features/xsql.rst
deleted file mode 100644 (file)
index 46a49f6..0000000
+++ /dev/null
@@ -1,150 +0,0 @@
-Running XSQL Console Commands and Queries
-=========================================
-
-XSQL Overview
--------------
-
-XSQL is an XML-based query language that describes simple stored procedures
-which parse XML data, query or update database tables, and compose XML output.
-XSQL allows you to query tree models like a sequential database. For example,
-you could run a query that lists all of the ports configured on a particular
-module and their attributes.
-
-The following sections cover the XSQL installation process, supported XSQL
-commands, and the way to structure queries.
-
-Installing XSQL
----------------
-
-To run commands from the XSQL console, you must first install XSQL on your
-system:
-
-#. Navigate to the directory in which you unzipped OpenDaylight
-#. Start Karaf::
-
-      ./bin/karaf
-
-#. Install XSQL::
-
-      feature:install odl-mdsal-xsql
-
-XSQL Console Commands
----------------------
-
-To enter a command in the XSQL console, structure the command as follows::
-
-   odl:xsql _<XSQL command>_
-
-The following table describes the commands supported in this OpenDaylight
-release.
-
-Supported XSQL Console Commands
-
-+-----------------+-------------------------------------------------------------------------------+
-| *Command*       | *Description*                                                                 |
-+=================+===============================================================================+
-| r               | Repeats the last command you executed.                                        |
-+-----------------+-------------------------------------------------------------------------------+
-| list vtables    | Lists the schema node containers that are currently installed. Whenever an    |
-|                 | OpenDaylight module is installed, its YANG model is placed in the schema      |
-|                 | context. At that point, the  XSQL receives a notification, confirms that the  |
-|                 | module's YANG model resides in the schema context and then maps the model to  |
-|                 | XSQL by setting up the necessary vtables and vfields. This command is useful  |
-|                 | when you need to determine vtable information for a query.                    |
-+-----------------+-------------------------------------------------------------------------------+
-| list vfields    | Lists the vfields present in a specific vtable. This command is useful when   |
-| *<vtable name>* | you need to determine vfields information for a query.                        |
-+-----------------+-------------------------------------------------------------------------------+
-| jdbc            | When the ODL server is behind a firewall, and the JDBC client cannot connect  |
-| *<ip address>*  | to the JDBC server, run this command to start the client as a server and      |
-|                 | establish a connection.                                                       |
-+-----------------+-------------------------------------------------------------------------------+
-| exit            | Closes the console.                                                           |
-+-----------------+-------------------------------------------------------------------------------+
-| tocsv           | Enables or disables the forwarding of query output as a .csv file.            |
-+-----------------+-------------------------------------------------------------------------------+
-| filename        | Specifies the .tocsv file to which the query data is exported. If you do not  |
-| *<filename>*    | specify a value for this option when the toccsv option is enabled, the        |
-|                 | filename for the query data file is generated automatically.                  |
-+-----------------+-------------------------------------------------------------------------------+
-
-XSQL Queries
-------------
-
-You can run a query to extract information that meets the criteria you specify
-using the information provided by the *list vtables* and *list vfields*
-_<vtable name>_ commands.  Any query you run should be structured as follows:
-
-*select* _<vfields you want to search for, separated by a comma and a space>_
-*from* _<vtables you want to search in, separated by a comma and a space>_
-*where* _<criteria>_ *'*_<criteria operator>_*';*
-
-For example, if you want to search the nodes/node ID field in the
-nodes/node-connector table and find every instance of the Hardware-Address
-object that contains _BA_ in its text string, enter the following query::
-
-   select nodes/node.ID from nodes/node-connector where Hardware-Address like '%BA%';
-
-The following criteria operators are supported:
-
-Supported XSQL Query Criteria Operators
-
-+--------------------+----------------------------------------------------------------------+
-| Criteria Operators | Description                                                          |
-+====================+======================================================================+
-| *=*                | Lists results that equal the value you specify.                      |
-+--------------------+----------------------------------------------------------------------+
-| *!=*               | Lists results that do not equal the value you specify.               |
-+--------------------+----------------------------------------------------------------------+
-| *like*             | Lists results that contain the substring you specify. For            |
-|                    | example, if you specify *like %BC%*, every string that contains      |
-|                    | that particular substring is displayed.                              |
-+--------------------+----------------------------------------------------------------------+
-| *<*                | Lists results that are less than the value you specify.              |
-+--------------------+----------------------------------------------------------------------+
-| *>*                | Lists results that are more than the value you specify.              |
-+--------------------+----------------------------------------------------------------------+
-| *and*              | Lists results that match both values you specify.                    |
-+--------------------+----------------------------------------------------------------------+
-| *or*               | Lists results that match either of the two values you specify.       |
-+--------------------+----------------------------------------------------------------------+
-| *>=*               | Lists results that are more than or equal to the value you specify.  |
-+--------------------+----------------------------------------------------------------------+
-| *<=*               | Lists results that are less than or equal to the value you specify.  |
-+--------------------+----------------------------------------------------------------------+
-| *is null*          | Lists results for which no value is assigned.                        |
-+--------------------+----------------------------------------------------------------------+
-| *not null*         | Lists results for which any value is assigned.                       |
-+--------------------+----------------------------------------------------------------------+
-| *skip*             | Use this operator to list matching results from a child node,        |
-|                    | even if its parent node does not meet the specified criteria.        |
-|                    | See the following example for more information.                      |
-+--------------------+----------------------------------------------------------------------+
-
-Example: Skip Criteria Operator
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If you are looking at the following structure and want to determine all of the
-ports that belong to a YY type module:
-
-* Network Element 1
-
-  * Module 1, Type XX
-
-    * Module 1.1, Type YY
-
-      * Port 1
-      * Port 2
-
-  * Module 2, Type YY
-
-    * Port 1
-    * Port 2
-
-If you specify *Module.Type='YY'* in your query criteria, the ports associated
-with module 1.1 will not be returned since its parent module is type XX.
-Instead, enter *Module.Type='YY' or skip Module!='YY'*. This tells XSQL to
-disregard any parent module data that does not meet the type YY criteria and
-collect results for any matching child modules. In this example, you are
-instructing the query to skip module 1 and collect the relevant data from
-module 1.1.
index 4457d6c46e53213a485c37c107a59392d5c0d38c..022a6922e9f9b8782a76f1711ab194e4dc5c2160 100644 (file)
@@ -201,9 +201,7 @@ Securing OpenDaylight using AAA
 ===============================
 
 AAA stands for Authentication, Authorization, and Accounting. All three of
-can help improve the security posture of and OpenDaylight deployment. In this
-release, only authentication is fully supported, while authorization is an
-experimental feature and accounting remains a work in progress.
+these services can help improve the security posture of an OpenDaylight deployment.
 
 The vast majority of OpenDaylight's northbound APIs (and all RESTCONF APIs) are
 protected by AAA by default when installing the +odl-restconf+ feature. In the
index f33e8158d8a86f5136b3863aa763b167edf0e0bb..d711df6f5feda00358b2f3c42054ec72ca6c5671 100644 (file)
@@ -58,6 +58,7 @@ participate in the development of OpenDaylight or would like to start.
    submodules/genius/docs/index
    submodules/infrautils/docs/index
    submodules/netvirt/docs/contributor-guide/index
+   submodules/openflowplugin/docs/index
 
 .. Commenting the below out until we actually use it
 .. Indices and tables
index 4acfbdeb16b827185c8aff8ba60e5e0bc3b2740b..7b1966539415bb2794bdd7532c44973c42be9191 100644 (file)
@@ -70,7 +70,6 @@ Project-specific Release Notes
    :glob:
    :maxdepth: 1
 
-   projects/*
 
 Service Release Notes
 =====================
index b1f691a61d92b761f1e535f38662ecefb828c571..8fbfaac6837eb81bbf0b901e0d0e4a92bb0d156b 100644 (file)
@@ -5,23 +5,17 @@ Infrautils
 Major Features
 ==============
 
-We have done a lot of clean-up and minor fixes for bugs reported via Bugzilla.
-
-Major changes delivered in this release are:
-
-* Job Coordinator: enables executing jobs in a parallel/sequential fashion, based on their keys (contribution from genius project)
-* Ready Framework: new framework to indicate system readiness, initial version
-* New JUnit Test Rules RunUntilFailureRule, LogCaptureRule, and LogRule
-
 odl-infrautils-all
 ------------------
 
-* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/infrautils-features/src/main/features/features.xml;hb=stable/carbon
+* **Feature URL:** https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=blob;f=common/features/odl-infrautils-all/pom.xml;hb=stable/nitrogen
 * **Feature Description:**  This feature exposes all infrautils framework features
 * **Top Level:** Yes
 * **User Facing:** No
 * **Experimental:** Yes
-* **CSIT Test:** none
+* **CSIT Test:** covered by Netvirt and Genius CSITs
+  * https://jenkins.opendaylight.org/releng/view/netvirt-csit/job/netvirt-csit-1node-openstack-ocata-upstream-stateful-nitrogen/
+  * https://jenkins.opendaylight.org/releng/view/genius/job/genius-csit-1node-upstream-all-nitrogen/
 
 .. note that this is experimental until the system test waiver is granted
 .. on this thread:
@@ -36,7 +30,7 @@ Documentation
 
 * **Developer Guide(s):**
 
-  * :ref:`infrautils-dev-guide`
+  * :doc:`Developer Guide </submodules/infrautils/docs/index>`
 
 Security Considerations
 =======================
@@ -46,9 +40,10 @@ Security Considerations
 Quality Assurance
 =================
 
-* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=66717>`_ (43.6% line coverage)
+* `Link to Sonar Report <https://sonar.opendaylight.org/overview?id=66717>`_
 * Project infrautils provides low-level technical framework utilities
-  and therefore no CSIT automated system testing is available
+  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
 ---------
@@ -58,9 +53,18 @@ Migration
 Compatibility
 -------------
 
-* This release is compatible with previous release
-* Async API was removed (dead code, not used by any odl projects)
-* No configuration changes made
+* Is this release compatible with the previous release?
+
+  * Functionality is fully backwards compatible.
+
+* Any API changes?
+
+  * New APIs added for system ready
+  * New APIs added for jobcoordinator
+
+* Any configuration changes?
+
+  * No
 
 Bugs Fixed
 ----------
diff --git a/docs/release-process/milestone-readouts/m1/dlux.rst b/docs/release-process/milestone-readouts/m1/dlux.rst
new file mode 100644 (file)
index 0000000..47228b8
--- /dev/null
@@ -0,0 +1,71 @@
+====
+Dlux
+====
+
+1. Project PTL:
+
+   - Maxime Millette Coulombe
+   - mmcoulombe@inocybe.com
+   - mmcoulombe
+   - I have reviewed the PTL Requirements
+
+2. Project Contact:
+
+   - Daniel Malachovsky
+   - dmalacho@cisco.com
+   - malachovsky
+
+3. Test Contact:
+
+   - Daniel Malachovsky
+   - dmalacho@cisco.com
+   - malachovsky
+
+4. Documentation Contact
+
+   - Daniel Malachovsky
+   - dmalacho@cisco.com
+   - malachovsky
+
+5. Does your project have any updates on any previously-incomplete items from
+   prior milestone readouts? (Yes/No)
+
+   - No
+
+6. Were project-specific deliverables planned for this milestone delivered
+   successfully? (No Deliverables/Yes/No)
+
+   - No Deliverables
+
+7. Does your project have any special needs in CI Infrastructure? (Yes/No)
+
+   - No
+
+8. Is your project release plan finalized? (Yes/No)
+
+   - Yes https://wiki.opendaylight.org/view/OpenDaylight_dlux:Oxygen_Release_Plan
+
+9. Do you have all APIs intended to be externally consumable listed? (Yes/No/Not Applicable)
+
+   - Not Applicable
+
+   - Does each API have a useful short name? NA
+   - Are the Java interface and/or YANG files listed for each API? NA
+   - Are they labeled as tentative, provisional, or stable as appropriate for
+     each API? NA
+   - Do you call out the OSGi bundles and/or Karaf features providing the API
+     for each API? NA
+
+10. Have all project dependencies requests on other projects' release plans
+    been acknowledged and documented by upstream projects? (Yes/No)
+
+    - No requests on upstream projects
+
+11. Will your project have top-level features not requiring system test? (Yes/No)
+
+    - No
+
+12. Will your project use the OpenDaylight CI infrastructure for testing
+    top-level features requiring system test? (Yes/No)
+
+    - Yes
diff --git a/docs/release-process/milestone-readouts/m1/dluxapps.rst b/docs/release-process/milestone-readouts/m1/dluxapps.rst
new file mode 100644 (file)
index 0000000..39334fd
--- /dev/null
@@ -0,0 +1,71 @@
+========
+DLuxApps
+========
+
+1. Project PTL:
+
+   - Daniel Malachovsky
+   - dmalacho@cisco.com
+   - malachovsky
+   - I have reviewed the PTL Requirements
+
+2. Project Contact:
+
+   - Daniel Malachovsky
+   - dmalacho@cisco.com
+   - malachovsky
+
+3. Test Contact:
+
+   - Lubomir Balogh
+   - lubalogh@cisco.com
+   - lubalogh
+
+4. Documentation Contact
+
+   - Daniel Malachovsky
+   - dmalacho@cisco.com
+   - malachovsky
+
+5. Does your project have any updates on any previously-incomplete items from
+   prior milestone readouts? (Yes/No)
+
+   - No
+
+6. Were project-specific deliverables planned for this milestone delivered
+   successfully? (No Deliverables/Yes/No)
+
+   - No Deliverables
+
+7. Does your project have any special needs in CI Infrastructure? (Yes/No)
+
+   - No
+
+8. Is your project release plan finalized? (Yes/No)
+
+   - Yes https://wiki.opendaylight.org/view/DluxApps:Oxygen_Release_Plan
+
+9. Do you have all APIs intended to be externally consumable listed? (Yes/No/Not Applicable)
+
+   - Not Applicable
+
+   - Does each API have a useful short name? NA
+   - Are the Java interface and/or YANG files listed for each API? NA
+   - Are they labeled as tentative, provisional, or stable as appropriate for
+     each API? NA
+   - Do you call out the OSGi bundles and/or Karaf features providing the API
+     for each API? NA
+
+10. Have all project dependencies requests on other projects' release plans
+    been acknowledged and documented by upstream projects? (Yes/No)
+
+    - No requests on upstream projects
+
+11. Will your project have top-level features not requiring system test? (Yes/No)
+
+    - No
+
+12. Will your project use the OpenDaylight CI infrastructure for testing
+    top-level features requiring system test? (Yes/No)
+
+    - Yes
diff --git a/docs/release-process/milestone-readouts/m1/faas.rst b/docs/release-process/milestone-readouts/m1/faas.rst
new file mode 100644 (file)
index 0000000..4f0e6f7
--- /dev/null
@@ -0,0 +1,71 @@
+====
+FaaS
+====
+
+1. Project PTL:
+
+   - Xingjun Chu
+   - xingjun.chu@huawei.com
+   - xingjun
+   - I have reviewed the PTL Requirements
+
+2. Project Contact:
+
+   - Xingjun Chu
+   - xingjun.chu@huawei.com
+   - xingjun
+
+3. Test Contact:
+
+   - Xingjun Chu
+   - xingjun.chu@huawei.com
+   - xingjun
+
+4. Documentation Contact
+
+   - Xingjun Chu
+   - Xingjun.Chu@huawei.com
+   - xingjun
+
+5. Does your project have any updates on any previously-incomplete items from
+   prior milestone readouts?
+
+   - No
+
+6. Were project-specific deliverables planned for this milestone delivered
+   successfully? (No Deliverables/Yes/No)
+
+   - No
+
+7. Does your project have any special needs in CI Infrastructure? (Yes/No)
+
+   - No
+
+8. Is your project release plan finalized?  (Yes/No)
+
+   - Yes
+   - https://wiki.opendaylight.org/view/FaaS:Oxygen_Release_Plan
+
+9. Do you have all APIs intended to be externally consumable listed? Yes
+
+   - Does each API have a useful short name? Yes
+   - Are the Java interface and/or YANG files listed for each API? Yes
+   - Are they labeled as tentative, provisional, or stable as appropriate for
+     each API? Yes
+   - Do you call out the OSGi bundles and/or Karaf features providing the API
+     for each API? Yes
+
+10. Have all project dependencies requests on other projects' release plans
+    been acknowledged and documented by upstream projects?
+
+    - Yes
+
+11. Will your project have top-level features not requiring system test?
+    (Yes/No)
+
+    - No
+
+12. Will your project use the OpenDaylight CI infrastructure for testing
+    top-level features requiring system test? (Yes/No)
+
+    - Yes
diff --git a/docs/release-process/milestone-readouts/m1/opflex.rst b/docs/release-process/milestone-readouts/m1/opflex.rst
new file mode 100644 (file)
index 0000000..f1e564c
--- /dev/null
@@ -0,0 +1,73 @@
+======
+OpFlex
+======
+
+1. Project PTL:
+
+   - Rob Adams
+   - readams@readams.net
+   - readams
+   - I have reviewed the PTL Requirements
+
+2. Project Contact:
+
+   - Rob Adams
+   - readams@readams.net
+   - readams
+
+3. Test Contact:
+
+   - Rob Adams
+   - readams@readams.net
+   - readams
+
+4. Documentation Contact
+
+   - Rob Adams
+   - readams@readams.net
+   - readams
+
+5. Does your project have any updates on any previously-incomplete items from
+   prior milestone readouts?
+
+   - No
+
+6. Were project-specific deliverables planned for this milestone delivered
+   successfully?
+
+   - No deliverables
+
+7. Does your project have any special needs in CI Infrastructure ? (Yes/No)
+
+   - No
+
+8. Is your project release plan finalized?  (Yes/No)
+
+   - No - I seem to have lost the ability to edit the wiki.  This will
+     be a very minor release with incremental changes and/or bug fixes.
+
+9. Do you have all APIs intended to be externally consumable listed? (Yes/No/Not Applicable)
+
+   - Does each API have a useful short name? NA
+   - Are the Java interface and/or YANG files listed for each API? NA
+   - Are they labeled as tentative, provisional, or stable as appropriate for
+     each API? NA
+   - Do you call out the OSGi bundles and/or Karaf features providing the API
+     for each API? NA
+
+10. Have all project dependencies requests on other projects' release plans
+    been acknowledged and documented by upstream projects?  (Yes/No)
+
+    - None
+
+11. Will your project have top-level features not requiring system test?
+    (Yes/No)
+
+    - NA
+
+12. Will your project use the OpenDaylight CI infrastructure for testing
+    top-level features requiring system test? (Yes/No)
+
+    - We have no top-level Karaf features, but the code is unit tested
+      in ODL infra and integration tested in our automated lab
+      infrastructure for integration with Kubernetes, OpenStack and ACI.
diff --git a/docs/release-process/milestone-readouts/m1/snmp.rst b/docs/release-process/milestone-readouts/m1/snmp.rst
new file mode 100644 (file)
index 0000000..f56eddd
--- /dev/null
@@ -0,0 +1,83 @@
+====
+SNMP
+====
+
+1. Project PTL:
+
+   - Ryan Goulding
+   - ryandgoulding@gmail.com
+   - rgoulding
+   - Yes, I have reviewed the PTL Requirements [1]_
+
+2. Project Contact:
+
+   - Ryan Goulding
+   - ryandgoulding@gmail.com
+   - rgoulding
+
+3. Test Contact:
+
+   - Ryan Goulding
+   - ryandgoulding@gmail.com
+   - rgoulding
+
+4. Documentation Contact
+
+   - Ryan Goulding
+   - ryandgoulding@gmail.com
+   - rgoulding
+
+5. Does your project have any updates on any previously-incomplete items from
+   prior milestone readouts?
+
+   - Yes.  We are still working on reaching out and cleaning up the committers lists.
+
+6. Were project-specific deliverables planned for this milestone delivered
+   successfully?
+
+   - No Deliverables
+
+7. Does your project have any special needs in CI Infrastructure [2]_?
+
+   - No
+
+8. Is your project release plan finalized?
+
+   - Yes, available here: `Release plan <https://wiki.opendaylight.org/view/SNMP_Plugin:Oxygen_Release_Plan>`_
+
+9. Do you have all APIs intended to be externally consumable listed?
+
+   - Does each API have a useful short name? *Yes*
+   - Are the Java interface and/or YANG files listed for each API? *Yes*
+   - Are they labeled as tentative, provisional, or stable as appropriate for
+     each API? *Yes*
+   - Do you call out the OSGi bundles and/or Karaf features providing the API
+     for each API? *Yes*
+
+10. Have all project dependencies requests on other projects' release plans
+    been acknowledged and documented by upstream projects?
+
+    - controller, Implicit acknowledgement
+    - mdsal, Implicit acknowledgement
+    - odlparent, Implicit acknowledgement
+    - yangtools, Implicit acknowledgement
+
+
+11. Will your project have top-level features not requiring system test?
+
+    - No
+
+12. Will your project use the OpenDaylight CI infrastructure for testing
+    top-level features requiring system test?
+
+    - Yes
+
+.. [1] Be sure to read the responsibilities of being a project lead under
+       Leadership & Communication in the Requirements for Participation section
+       of the release plan:
+       https://wiki.opendaylight.org/view/Simultaneous_Release:Oxygen_Release_Plan#Requirements_for_Participation
+.. [2] Special needs include tools or configuration.  Note that generally, the
+       only available tools in CI are basic RHEL/CentOS linux images with Java.
+       You should note and ask for anything beyond that here.  Email
+       helpdesk@opendaylight.org
+
diff --git a/docs/release-process/milestone-readouts/m1/tsdr.rst b/docs/release-process/milestone-readouts/m1/tsdr.rst
new file mode 100644 (file)
index 0000000..34ae73a
--- /dev/null
@@ -0,0 +1,82 @@
+====
+TSDR
+====
+
+1. Project PTL:
+
+   - YuLing Chen
+   - yulingchen54@gmail.com
+   - yuling_c
+   - Yes, I have reviewed the PTL Requirements [1]_
+
+2. Project Contact:
+
+   - YuLing Chen
+   - yulingchen54@gmail.com
+   - yuling_c
+
+3. Test Contact:
+
+   - YuLing Chen
+   - yulingchen54@gmail.com
+   - yuling_c
+
+4. Documentation Contact
+
+   - YuLing Chen
+   - yulingchen54@gmail.com
+   - yuling_c
+
+5. Does your project have any updates on any previously-incomplete items from
+   prior milestone readouts?
+
+   - No
+
+6. Were project-specific deliverables planned for this milestone delivered
+   successfully?
+
+   - No Deliverables
+
+7. Does your project have any special needs in CI Infrastructure [2]_?
+
+   - No
+
+8. Is your project release plan finalized?
+
+   - Yes, available here: `Release plan <https://wiki.opendaylight.org/view/TSDR:TSDR_Oxygen_Release_Plan>`
+
+9. Do you have all APIs intended to be externally consumable listed?
+
+   - Does each API have a useful short name? *Yes*
+   - Are the Java interface and/or YANG files listed for each API? *Yes*
+   - Are they labeled as tentative, provisional, or stable as appropriate for
+     each API? *Yes*
+   - Do you call out the OSGi bundles and/or Karaf features providing the API
+     for each API? *Yes*
+
+10. Have all project dependencies requests on other projects' release plans
+    been acknowledged and documented by upstream projects?
+
+    - controller, Implicit acknowledgement
+    - mdsal, Implicit acknowledgement
+    - odlparent, Implicit acknowledgement
+    - yangtools, Implicit acknowledgement
+
+
+11. Will your project have top-level features not requiring system test?
+
+    - No
+
+12. Will your project use the OpenDaylight CI infrastructure for testing
+    top-level features requiring system test?
+
+    - Yes
+
+.. [1] Be sure to read the responsibilities of being a project lead under
+       Leadership & Communication in the Requirements for Participation section
+       of the release plan:
+       https://wiki.opendaylight.org/view/Simultaneous_Release:Oxygen_Release_Plan#Requirements_for_Participation
+.. [2] Special needs include tools or configuration.  Note that generally, the
+       only available tools in CI are basic RHEL/CentOS linux images with Java.
+       You should note and ask for anything beyond that here.  Email
+       helpdesk@opendaylight.org
diff --git a/docs/release-process/milestone-readouts/m2/alto.rst b/docs/release-process/milestone-readouts/m2/alto.rst
new file mode 100644 (file)
index 0000000..05c5509
--- /dev/null
@@ -0,0 +1,84 @@
+====
+ALTO
+====
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them?
+     N/A
+
+   - Also please list all dropped APIs.
+     N/A
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)?
+   Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository?
+   Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=alto.git;a=blob;f=alto-release-features/features-alto/pom.xml;h=9b6d26050f06c3d508853c7ce005d4bd1c4b096b;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml;h=d9dbcafaed73ad39695a25a06e4e8f0ceb79b904;hb=HEAD
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/alto.rst
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - User Guide(s).
+   - Developer Guide(s).
+   - Installation Guide(s).
+   - Release notes (mandatory).
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/alto-user-guide.rst;h=3093d9d546d2db987307a1fe0cb43daa9a5b4214;hb=HEAD
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   Yes
+
+   - https://jenkins.opendaylight.org/releng/view/alto/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature?
+   Yes
+
+   - https://wiki.opendaylight.org/view/ALTO:_System_Test_Plan
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category?
+   Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy?
+   Yes
diff --git a/docs/release-process/milestone-readouts/m2/bgpcep.rst b/docs/release-process/milestone-readouts/m2/bgpcep.rst
new file mode 100644 (file)
index 0000000..7e422cc
--- /dev/null
@@ -0,0 +1,101 @@
+===========
+BGP LS PCEP
+===========
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes/No
+
+   - https://wiki.opendaylight.org/view/BGP_LS_PCEP:Oxygen_Release_Plan#Externally_Consumable_APIs
+   - https://wiki.opendaylight.org/view/BGP_LS_PCEP:Oxygen_Release_Plan#Removed_APIs_and.2For_Functionality
+
+2. Are all your inter-project dependencies resolved?
+
+   - Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+
+   - No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository?
+
+   - Yes
+   - https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=features/bgp/src/main/features/features.xml;h=0ac6b0b0a2286515900879ed374e5138b61a49e2;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=features/pcep/src/main/features/features.xml;h=0ac6b0b0a2286515900879ed374e5138b61a49e2;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=features/bmp/src/main/features/features.xml;h=0ac6b0b0a2286515900879ed374e5138b61a49e2;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=features/rsvp/src/main/features/features.xml;h=0ac6b0b0a2286515900879ed374e5138b61a49e2;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=bgpcep.git;a=blob;f=features/extras/src/main/features/features.xml;h=0ac6b0b0a2286515900879ed374e5138b61a49e2;hb=refs/heads/master
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - odl-bgpcep-bgp
+   - odl-bgpcep-bmp
+   - odl-bgpcep-pcep
+   - odl-bgpcep-rsvp
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - developer guide
+   - user guide
+   - Release notes (mandatory).
+
+2. Have you checked in a reStructuredText outline to the docs repository?
+
+   - Yes.
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/bgp-developer-guide.rst;h=0e5df8030a53fc22aeb044982758f362271d91b3;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/bgp-monitoring-protocol-developer-guide.rst;h=d83bbc7dce561e9ac6319cadba0a1460003d9641;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/pcep-developer-guide.rst;h=d1b48bfbfb2b91b1002e6fff99cb9360490366ea;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/bgp-user-guide.rst;h=307de691444779efdeda065d9f5e98791ef1bfc8;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/bgp-monitoring-protocol-user-guide.rst;h=5153494111add81a13c3582d56d240ce782e63ec;hb=refs/heads/master
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/pcep-user-guide.rst;h=8cba92ecc27a7696656486b85649c4f740f8f6f9;hb=refs/heads/master
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+
+   - Yes.
+   - https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-mixed-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-bgp-ingest-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-periodic-throughpcep-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/bgpcep/job/bgpcep-csit-1node-userfeatures-all-oxygen/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature?
+
+   - Yes
+   - https://wiki.opendaylight.org/view/BGP_LS_PCEP:Oxygen_Feature_Tests
+
+3. Have you integrated odlparent 3 / yangtools 2?
+
+   - No
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone? No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/coe.rst b/docs/release-process/milestone-readouts/m2/coe.rst
new file mode 100644 (file)
index 0000000..c88cae6
--- /dev/null
@@ -0,0 +1,112 @@
+===
+COE
+===
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes/No
+
+   Yes. No tentative API.
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+
+     N/A
+
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? (Yes/No) <link to e-mail>
+
+     N/A
+
+   - Also please list all dropped APIs.
+
+     N/A
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? (Yes/No)
+
+   Yes.
+
+3. Were there any project-specific deliverables planned for this milestone?
+   Yes/No
+
+   No.
+
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? (Yes/No)
+
+   Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - odl-coe: https://git.opendaylight.org/gerrit/gitweb?p=coe.git;a=blob;f=features/odl-coe/pom.xml
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - Coe Design Document
+     https://wiki.opendaylight.org/view/COE:Design_doc
+   - An installation guide for any top-level features that require more than
+     feature:install <feature-name> to install.
+     N/A as this is covered by service provider, e.g. netvirt
+   - Release notes (mandatory) [2]_.
+     COE will be doing a release only in Oxygen, will be adding that towards the end
+   - Optional tutorials and how-tos.
+     N/A
+
+2. Have you checked in a reStructuredText outline to the docs repository? (Yes/No)
+
+   Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=coe.git;a=tree;f=docs
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   (Yes/No)
+
+   N/A (System test will be covered by the service provider which is going to be Netvirt)
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? (Yes/No)
+
+   N/A as 1.
+
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   (Yes/No)
+
+   No.
+
+2. Have you updated your project facts with the project type category? (Yes/No)
+
+   Yes.
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? (Yes/No)
+
+   Yes.
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/genius.rst b/docs/release-process/milestone-readouts/m2/genius.rst
new file mode 100644 (file)
index 0000000..4e803d5
--- /dev/null
@@ -0,0 +1,130 @@
+======
+Genius
+======
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.  NA
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   Updates to mdsalutil-api module:
+
+   - Following utility classes are removed:
+
+     - ClusteringUtils
+     - EntityOwnerUtils
+
+   - Above utility classes are replaced by following new class:
+
+     - EntityOwnershipUtils
+
+   Updates to ITM api:
+
+   - Additional new RPCs will be added by ITM scale improvements:
+
+     - itm-rpc:get-egress-action
+     - itm-rpc:set-bfd-enable-on-tunnel
+
+   - Link to gerrit review for spec:
+
+     - https://git.opendaylight.org/gerrit/#/c/65809/
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone? No
+
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=genius.git;a=blob_plain;f=features/genius-features/pom.xml
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml;h=d9dbcafaed73ad39695a25a06e4e8f0ceb79b904;hb=HEAD
+
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   * **odl-genius** : 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.
+
+   * **odl-genius-rest** : This feature includes RESTCONF with 'odl-genius'
+     feature.
+
+   * **odl-genius-api** : This feature includes API for all the functionalities
+     provided by Genius.
+
+   * **odl-genius-fcaps-application** : includes Genius FCAPS application.
+
+   * **odl-genius-fcaps-framework** : includes Genius FCAPS Framework.
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - One user/operator guide section per user-facing feature.
+
+     - https://wiki.opendaylight.org/view/Genius_:_An_Overview
+     - https://wiki.opendaylight.org/view/Genius:_User_Guide
+   - One developer guide per top-level feature.
+
+     - http://docs.opendaylight.org/en/latest/submodules/genius/docs/index.html
+
+   - An installation guide for any top-level features that require more than
+     feature:install <feature-name> to install. --N/A
+
+   - Release notes (mandatory) [2]_.
+
+   - Optional tutorials and how-tos.
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - Link to gerrit patch:
+
+     - https://git.opendaylight.org/gerrit/#/c/53072/
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features? Yes
+
+   - https://jenkins.opendaylight.org/releng/view/genius/
+
+   - Link to test report:
+
+     - 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/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? Yes
+
+   - Link to test plans:
+
+     - https://wiki.opendaylight.org/view/Genius:test_plan
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone? No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
+
diff --git a/docs/release-process/milestone-readouts/m2/groupbasedpolicy.rst b/docs/release-process/milestone-readouts/m2/groupbasedpolicy.rst
new file mode 100644 (file)
index 0000000..805a5f7
--- /dev/null
@@ -0,0 +1,79 @@
+================
+GROUPBASEDPOLICY
+================
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? N/A
+   - Also please list all dropped APIs.
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? N/A
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - see list of external APIs here:
+     https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Releases/Oxygen/Release_plan#Externally_Consumable_APIs.
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - One user/operator guide section per user-facing feature.
+   - Release notes (mandatory).
+
+2. Have you checked in a reStructuredText outline to the docs repository? No
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   Yes
+
+   - 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/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? No
+
+   - no stable features yet
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/honeycomb-vbd.rst b/docs/release-process/milestone-readouts/m2/honeycomb-vbd.rst
new file mode 100644 (file)
index 0000000..2a00492
--- /dev/null
@@ -0,0 +1,77 @@
+=============
+HONEYCOMB/VBD
+=============
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? N/A
+   - Also please list all dropped APIs.
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? N/A
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - see list of external APIs here:
+     https://wiki.opendaylight.org/view/Honeycomb/VBD/API
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - Release notes (mandatory).
+   - Optional tutorials and how-tos.
+
+2. Have you checked in a reStructuredText outline to the docs repository? No
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   No
+
+   - all marked as experimental
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? No
+
+   - no stable features yet
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/infrautils.rst b/docs/release-process/milestone-readouts/m2/infrautils.rst
new file mode 100644 (file)
index 0000000..57d05eb
--- /dev/null
@@ -0,0 +1,72 @@
+==========
+InfraUtils
+==========
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone? No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/infrautils.rst
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - Developer Guide, JavaDocs
+
+2. Have you checked in a reStructuredText outline to the docs repository? (Yes/No)
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=infrautils.git;a=tree;f=docs
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features? N/A
+
+   - Covered by application CSITs
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? N/A
+
+3. Have you integrated odlparent 3 / yangtools 2? No
+
+   - (If yes, link to gerrit patch)
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone? No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/l2switch.rst b/docs/release-process/milestone-readouts/m2/l2switch.rst
new file mode 100644 (file)
index 0000000..5a12df1
--- /dev/null
@@ -0,0 +1,87 @@
+========
+l2switch
+========
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: **Yes, available in documentation. No change from previous releases.**
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     **N/A**
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? **N/A**
+   - Also please list all dropped APIs.
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? **Yes**
+
+3. Were there any project-specific deliverables planned for this milestone? **No**
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? **Yes**
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   :odl-l2switch-packethandler: Decodes the packets coming to the controller
+       and dispatches them to the other modules
+
+   :odl-l2switch-loopremover: Runs STP and marks NodeConnectors as forwarding
+       or blocking in the node inventory
+
+   :odl-l2switch-arphandler: Responds to incoming ARP requests with learned
+       addresses. In proactive-flood mode, floods traffic to all ports.
+
+   :odl-l2switch-addresstracker: Observes IPv4, IPv6, and ARP traffic incoming
+       via packethandler. Observations are written into the datastore for consumption
+
+   :odl-l2switch-hosttracker: Translates address observations from the network
+       (via addresstracker) into Hosts in the datastore
+
+   :odl-l2switch-switch: Installs bi-directional MAC to MAC flows based on
+       incoming ARP traffic
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - **User guide** http://docs.opendaylight.org/en/latest/user-guide/l2switch-user-guide.html
+   - **Developer guide**, sections per feature http://docs.opendaylight.org/en/latest/developer-guide/l2switch-developer-guide.html
+   - **Release notes** (mandatory) [2]_.
+
+2. Have you checked in a reStructuredText outline to the docs repository? **No**
+
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   **Yes**
+
+   - https://jenkins.opendaylight.org/releng/view/l2switch/job/l2switch-csit-1node-switch-all-oxygen/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? **No**
+
+   - (If no, why?) **This project is in maintenance mode, and is used mostly as an introductory project to ODL. We don't consider any features as stable. For each top-level feature we maintain a CSIT test suite, but no test plan template as such**
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   **No**
+
+2. Have you updated your project facts with the project type category? **Yes**
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? **Yes**
+
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/nemo.rst b/docs/release-process/milestone-readouts/m2/nemo.rst
new file mode 100644 (file)
index 0000000..d725fd7
--- /dev/null
@@ -0,0 +1,72 @@
+====
+NEMO
+====
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No deliverables
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml;
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/nemo.rst;
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - User Guide, Developer Guide, Tutorials
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/nemo-user-guide.rst;
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/nemo-developer-guide.rst;
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features? Yes
+
+   - https://jenkins.opendaylight.org/releng/view/nemo/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? Yes
+
+   - https://wiki.opendaylight.org/view/NEMO:Integration_Test
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone? No deliverables
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/netvirt.rst b/docs/release-process/milestone-readouts/m2/netvirt.rst
new file mode 100644 (file)
index 0000000..84f48ea
--- /dev/null
@@ -0,0 +1,74 @@
+=======
+NetVirt
+=======
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone? No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/netvirt.rst
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - User Guide, Developer Guide, Tutorials
+
+2. Have you checked in a reStructuredText outline to the docs repository? (Yes/No)
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=netvirt.git;a=tree;f=docs;h=5eba14dcaa5780e9b4b9052924b2c7f5df7eee0c;hb=HEAD
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features? Yes
+
+   - https://jenkins.opendaylight.org/releng/view/netvirt-csit/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? Yes
+
+   - https://wiki.opendaylight.org/view/NetVirt:Integration_Test
+
+3. Have you integrated odlparent 3 / yangtools 2? No
+
+   - (If yes, link to gerrit patch)
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone? No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/neutron-northbound.rst b/docs/release-process/milestone-readouts/m2/neutron-northbound.rst
new file mode 100644 (file)
index 0000000..532aad9
--- /dev/null
@@ -0,0 +1,157 @@
+==================
+Neutron Northbound
+==================
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes/No
+
+   Yes. No tentative API.
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+
+     N/A
+
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? (Yes/No) <link to e-mail>
+
+     N/A
+
+   - Also please list all dropped APIs.
+
+     N/A
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? (Yes/No)
+
+   Yes.
+
+   - (If no, please list the features you were expecting that have not been delivered)
+
+     N/A
+
+   - (The respective project [1]_ you were expecting to receive them from)
+
+     N/A
+
+3. Were there any project-specific deliverables planned for this milestone?
+   Yes/No
+
+   No.
+
+   - (If so, were they delivered? Yes/No)
+
+     N/A
+
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? (Yes/No)
+
+   Yes
+
+   - Please provide link to gerrit patch
+
+     https://git.opendaylight.org/gerrit/#/c/58981/
+
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - For top-level and user-facing features, please provide a one-sentence
+     description a developer and/or user would find helpful.
+
+   - odl-neutron-service: Basic library for for openstack Neutron integration working with networking-odl
+
+
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   Yes. no updates from Carbon.
+
+   - One user/operator guide section per user-facing feature.
+     https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/neutron-service-user-guide.rst;hb=HEAD
+   - One developer guide per top-level feature.
+     - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/neutron-service-developer-guide.rst;hb=HEAD
+     - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/neutron-northbound.rst;hb=HEAD
+   - An installation guide for any top-level features that require more than
+     feature:install <feature-name> to install.
+     N/A as this is covered by openstack service provider, e.g. netvirt
+   - Release notes (mandatory) [2]_.
+     https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/neutron-northbound.rst;hb=HEAD
+   - Optional tutorials and how-tos.
+     N/A
+
+
+2. Have you checked in a reStructuredText outline to the docs repository? (Yes/No)
+
+   Yes
+
+   - Please provide link to gerrit patch
+
+     https://git.opendaylight.org/gerrit/#/c/44169/
+
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   (Yes/No)
+
+   No
+
+   - (If yes, link to test report)
+   - (If no, why?)
+
+     the project has requested system test weaver as before release.
+     https://lists.opendaylight.org/pipermail/release/2017-October/012703.html
+     Basically system test is done by openstack service provider like netvirt and also
+     openstack CI by networking-odl project.
+     https://review.openstack.org/#/c/521692/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? (Yes/No)
+
+   N/A as 1.
+
+   - (If yes, link to test plans)
+   - (If no, why?)
+
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   (Yes/No)
+
+   No.
+
+   - (If so, were they delivered? Yes/No )
+
+     N/A
+
+2. Have you updated your project facts with the project type category? (Yes/No)
+
+   Yes.
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? (Yes/No)
+
+   Yes.
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/opflex.rst b/docs/release-process/milestone-readouts/m2/opflex.rst
new file mode 100644 (file)
index 0000000..bca52bd
--- /dev/null
@@ -0,0 +1,78 @@
+======
+OpFlex
+======
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? N/A
+   - Also please list all dropped APIs: N/A
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes (N/A)
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - N/A
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - User guide for agent-ovs daemon
+   - Developer guide for libopflex, genie, agent-ovs
+   - Install guide for Red Hat/CentOS
+   - Release notes (mandatory)
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - `User guide <https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/opflex-agent-ovs-user-guide.rst;h=d7212fc4e9f0c1d2d188ee513868cc4c92fed14e;hb=refs/heads/master>`_
+   - `libopflex developer guide <https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/opflex-libopflex-developer-guide.rst;h=2f8d371e6c67d3339dd6c0d5b199e5ef9232c613;hb=refs/heads/master>`_
+   - `agent-ovs developer guide <https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/opflex-agent-ovs-developer-guide.rst;h=b7840c50ffc9ec7ab7dc38809707f0574e23a018;hb=refs/heads/master>`_
+   - `genie developer guide <https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/opflex-genie-developer-guide.rst;h=72128c3db852ca092865547cec22b507f55524b0;hb=refs/heads/master>`_
+   - `Install guide <https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/getting-started-guide/project-specific-guides/opflex.rst;h=9c732221727455ad35072c225098b8eb91b610e1;hb=refs/heads/master>`_
+   - Release notes pending
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   Yes
+
+   - No top-level features
+   - Testing exists in separate infrastructure
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? (Yes/No)
+
+   - `System Test <https://wiki.opendaylight.org/view/OpFlex:Oxygen_Feature_Integration_System_Test>`_
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy? Yes
diff --git a/docs/release-process/milestone-readouts/m2/packetcable.rst b/docs/release-process/milestone-readouts/m2/packetcable.rst
new file mode 100644 (file)
index 0000000..5c8ecc0
--- /dev/null
@@ -0,0 +1,77 @@
+===========
+Packetcable
+===========
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     There were no Tentative APIs in the Packetcable project.
+
+2. Are all your inter-project dependencies resolved? Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository?
+   Yes, but there are no new features for the Oxygen release of Packetcable
+   so no Gerrit patch is applicable.
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - odl-packetcable-policy-server
+   - The Packetcable Policy Server enables flow-based dynamic QoS for DOCSIS
+     infrastructure-based systems utilizing the COPS protocols.
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - Packetcable user/operator guide (includes install guide)
+   - Packetcable developer guide
+   - Packetcable Oxygen Release notes
+
+2. Have you checked in a reStructuredText outline to the docs repository? No
+
+   - As there are no planned changes to the project documentation for the
+     Oxygen release, the current document versions in the master branch
+     will be used.
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   Yes
+
+   - https://jenkins.opendaylight.org/releng/view/packetcable/job/packetcable-csit-1node-pcmm-all-oxygen/61/robot/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature?
+   No - Packetcable has no (official) stable features at this time.
+
+3. Have you integrated odlparent 3 / yangtools 2?  No
+
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category?
+   Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy?
+   Yes
diff --git a/docs/release-process/milestone-readouts/m2/sfc.rst b/docs/release-process/milestone-readouts/m2/sfc.rst
new file mode 100644 (file)
index 0000000..5ec5905
--- /dev/null
@@ -0,0 +1,110 @@
+=========================
+Service Function Chaining
+=========================
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? N/A
+
+   - Also please list all dropped APIs.
+     No APIs were dropped, but we did deprecate the RSP creation via RPC,
+     and it will be removed in Fluorine.
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone? No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? No
+
+   There will be 2 new SFC features in Oxygen: odl-sfc-shell and odl-sfc-statistics.
+   The odl-sfc-shell feature has been added to the integration git repo
+   in the gerrit patch below, but the odl-sfc-statistics feature is not
+   ready yet and will be added soon.
+
+   - https://git.opendaylight.org/gerrit/65684
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - For top-level and user-facing features, please provide a one-sentence
+     description a developer and/or user would find helpful.
+
+     - Top level, user-facing SFC features
+
+       - odl-sfc-netconf: Provides functionality to communicate with Netconf capable Service Functions.
+       - odl-sfc-scf-openflow: SFC stand-alone openflow classifier.
+       - odl-sfc-scf-vpp: SFC stand-alone vpp classifier.
+       - odl-sfc-openflow-renderer: Renderer functionality for OpenFlow capable switches.
+       - odl-sfclisp: Programs LISP capable switches.
+       - odl-sfc-sb-rest: Implements a South Bound Rest interface to send configuration to REST-capable switches.
+       - odl-sfc-ui: This feature is the SFC User Interface.
+       - odl-sfc-vnfm-tacker: Tacker VNF Manager interface.
+       - odl-sfc-ios-xe-renderer: Renderer functionality for IO XE switches that use netconf.
+       - odl-sfc-vpp-renderer: Renderer functionality for fd.io VPP (Vector Packet Processor) switches that use netconf.
+       - odl-sfc-pot: This feature implements a Proof of Transit for the Service Functions.
+
+     - Top level, non-user-facing SFC features consumed by the user-facing features above
+
+       - odl-sfc-genius: This feature implements the Genius utilities created by SFC project.
+       - odl-sfc-model: This feature defines and implements the SFC data model as specified here https://datatracker.ietf.org/doc/rfc7665/
+       - odl-sfc-pot-netconf-renderer: This feature implements the Netconf rendering for the Proof of Transit for the Service Functions.
+       - odl-sfc-provider: This feature provides an easy-to-use interface to the sfc-model.
+       - odl-sfc-provider-rest: This feature provides no functionality, and just installs the necessary features for SFC restconf.
+       - odl-sfc-ovs: This feature provides functionality for SFC to communicate with OVSDB for SFF configuration.
+       - odl-sfc-test-consumer: This feature is used for testing only.
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - A user guide for the SFC project.
+   - A developer guide for the SFC project.
+   - Release notes (mandatory) [2]_.
+
+2. Have you checked in a reStructuredText outline to the docs repository? No
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features? Yes
+
+   - https://jenkins.opendaylight.org/releng/view/sfc/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? No
+
+   - We're not ready with this yet.
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone? No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/sxp.rst b/docs/release-process/milestone-readouts/m2/sxp.rst
new file mode 100644 (file)
index 0000000..900c4c2
--- /dev/null
@@ -0,0 +1,84 @@
+============
+SXP
+============
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? N/A
+   - Also please list all dropped APIs. N/A
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No
+
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes/No)
+
+   - https://git.opendaylight.org/gerrit/#/c/59781/
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - odl-sxp-controller - Implementation of the SXP protocol
+   - odl-sxp-route - Masks the ODL cluster as a single device for the external
+     SXP devices
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - Developer guide
+   - User guide
+   - Release notes (mandatory)
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/sxp-user-guide.rst;h=ea2ce60ed85c9be80e9049260492e33814c34ab5;hb=HEAD
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/sxp-developer-guide.rst;h=020eae563872c7c292eeebe5893068ae85935f05;hb=HEAD
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   Yes
+
+   - https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-basic-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-filtering-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-periodic-performance-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-1node-topology-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-3node-periodic-clustering-all-oxygen/
+   - https://jenkins.opendaylight.org/releng/view/sxp/job/sxp-csit-3node-periodic-routing-all-oxygen/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? Yes
+
+   - https://wiki.opendaylight.org/view/SXP:Oxygen:System_Test_Plan
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/tsdr.rst b/docs/release-process/milestone-readouts/m2/tsdr.rst
new file mode 100644 (file)
index 0000000..13e0a74
--- /dev/null
@@ -0,0 +1,82 @@
+====
+TSDR
+====
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? N/A
+   - Also please list all dropped APIs.
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+   - https://git.opendaylight.org/gerrit/#/c/65830/
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/tsdr.rst
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - User Guide(s).
+   - Installation Guide(s).
+   - Release notes (mandatory).
+   - Tutorials and how-tos.
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/tsdr-user-guide.rst
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   Yes
+
+   - https://jenkins.opendaylight.org/releng/view/tsdr/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? Yes
+
+   - https://wiki.opendaylight.org/view/TSDR:TSDR_Oxygen_Testing_with_Results#Test_Cases_.26_Results
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/usc.rst b/docs/release-process/milestone-readouts/m2/usc.rst
new file mode 100644 (file)
index 0000000..d784d00
--- /dev/null
@@ -0,0 +1,72 @@
+===
+USC
+===
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   No deliverables
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml;
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/usc.rst;
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - User Guide, Developer Guide, Tutorials
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/unified-secure-channel.rst;
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/unified-secure-channel.rst;
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features? Yes
+
+   - https://jenkins.opendaylight.org/releng/view/usc/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? Yes
+
+   - https://wiki.opendaylight.org/view/USC:Integration_Test
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone? No deliverables
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
diff --git a/docs/release-process/milestone-readouts/m2/vtn.rst b/docs/release-process/milestone-readouts/m2/vtn.rst
new file mode 100644 (file)
index 0000000..c6fdb96
--- /dev/null
@@ -0,0 +1,84 @@
+===
+VTN
+===
+
+Please provide updates on any previously-incomplete items from prior milestone
+readouts.
+
+Functionality Freeze:
+---------------------
+
+1. Final list of externally consumable APIs defined: Yes
+
+   - If you had Tentative APIs, have they been moved to Provisional or dropped?
+     N/A
+   - If any of your Tentative APIs were dropped, have you notified all projects
+     that were expecting them? N/A
+   - Also please list all dropped APIs.
+
+2. Are all your inter-project dependencies resolved (i.e., have the other
+   projects you were counting on given you what you needed)? Yes
+
+3. Were there any project-specific deliverables planned for this milestone?
+   - No
+
+Karaf Features Defined:
+-----------------------
+
+1. Are all your project's features that are intended for release added to the
+   features.xml and checked into integration git repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=integration/distribution.git;a=blob;f=features/repos/index/pom.xml;h=d9dbcafaed73ad39695a25a06e4e8f0ceb79b904;hb=HEAD
+
+2. List all top-level, user-facing, and stable Karaf features for your project.
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/release-notes/projects/vtn.rst;h=2533053aa7b2bd5fe0d425f25cf29a67f2671006;hb=HEAD
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/developer-guide/virtual-tenant-network-(vtn).rst;h=810ca51907fb062516244b50a7f7a84ca6a8c9a9;hb=HEAD
+
+Documentation:
+--------------
+
+1. List the kinds of documentation you will provide including at least:
+
+   - User Guide(s).
+   - Developer Guide(s).
+   - Installation Guide(s).
+   - Release notes (mandatory).
+   - Tutorials and how-tos.
+
+2. Have you checked in a reStructuredText outline to the docs repository? Yes
+
+   - https://git.opendaylight.org/gerrit/gitweb?p=docs.git;a=blob;f=docs/user-guide/virtual-tenant-network-(vtn).rst;h=602e71bdfabc85641794e14a8c72082ed684e33d;hb=HEAD
+
+Integration and Test:
+---------------------
+
+1. Have you started automated system testing for your top-level features?
+   Yes
+
+   - https://jenkins.opendaylight.org/releng/view/vtn/
+
+2. Have you filled out basic system test plan template for each top-level
+   feature (karaf and not karaf) and a comprehensive system test plan template
+   including functionality, cluster, scalability, performance,
+   longevity/stability for each stable feature? Yes
+
+   - https://wiki.opendaylight.org/view/OpenDaylight_Virtual_Tenant_Network_(VTN):Integration_Test
+
+Project Specific:
+-----------------
+
+1. Were there any project-specific deliverables planned for this milestone?
+   No
+
+2. Have you updated your project facts with the project type category? Yes
+
+3. Do you acknowledge the changes to the RC Blocking Bug Policy [3]_? Yes
+
+.. [1] Note that you can only reasonably hold a project to something if you
+       formally asked for it during the release planning process and the project
+       team members acknowledged that ask saying they would do it.
+.. [2] Release notes must be updated prior to a major release. It is a good idea
+       to keep release notes as a living document when significant changes are
+       made.
+.. [3] https://lists.opendaylight.org/pipermail/tsc/2016-December/006468.html
index 73f4dd5eb852a6b5a970bcfb09f7bc4b6499c5da..2795f8745e85fa13b74a995d9a98563b009e77df 100644 (file)
@@ -73,6 +73,10 @@ Integration and Test:
    - (If yes, link to test plans)
    - (If no, why?)
 
+3. Have you integrated odlparent 3 / yangtools 2? (Yes/No/NA)
+
+   - (If yes, link to gerrit patch)
+
 Project Specific:
 -----------------
 
index 7b8b8e8563a27a16cd8a6221b5f662857f855bf1..7e3d7d37313d84c21ac2707f2b3474410328cb02 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 7b8b8e8563a27a16cd8a6221b5f662857f855bf1
+Subproject commit 7e3d7d37313d84c21ac2707f2b3474410328cb02
index b799eabd7f9f9d869506dd40aeaad71820374d46..dd553db0255426051b8fd7f201a9895759c8bcba 160000 (submodule)
@@ -1 +1 @@
-Subproject commit b799eabd7f9f9d869506dd40aeaad71820374d46
+Subproject commit dd553db0255426051b8fd7f201a9895759c8bcba
index 2339962317b71a99778d8310a85cbaf733760494..1a7ed995bef73ae40995f06559129c1876e5a6d2 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 2339962317b71a99778d8310a85cbaf733760494
+Subproject commit 1a7ed995bef73ae40995f06559129c1876e5a6d2
index 1e6ce4f5a00f17a68b4bed12a6fcb3218889c006..a065a33e25c9a7b79b7deb97c14db36e2dd844a4 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 1e6ce4f5a00f17a68b4bed12a6fcb3218889c006
+Subproject commit a065a33e25c9a7b79b7deb97c14db36e2dd844a4
index 78fc80269e4f54d64ff5e3074aa68a80cf74bcf8..29b2526cce33cf26649490633f3c257676c551bf 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 78fc80269e4f54d64ff5e3074aa68a80cf74bcf8
+Subproject commit 29b2526cce33cf26649490633f3c257676c551bf
index f2b82755e9ea88bf49fccd8291b72f5aca47cd15..b7f1c4bfb374415e693c6cd315a49b6b0b4f9e7e 160000 (submodule)
@@ -1 +1 @@
-Subproject commit f2b82755e9ea88bf49fccd8291b72f5aca47cd15
+Subproject commit b7f1c4bfb374415e693c6cd315a49b6b0b4f9e7e
index 894864078528709ca28f653cdfc20a24c5d7c955..bb05669a1e2f1bc4e123a8ae5fa674b123a42538 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 894864078528709ca28f653cdfc20a24c5d7c955
+Subproject commit bb05669a1e2f1bc4e123a8ae5fa674b123a42538
index f01da36f40cdcc21a88c40330b43334d3eb06a84..ba817d21fd9e15ff4fb2f06c5d8a7ea320b83672 160000 (submodule)
@@ -1 +1 @@
-Subproject commit f01da36f40cdcc21a88c40330b43334d3eb06a84
+Subproject commit ba817d21fd9e15ff4fb2f06c5d8a7ea320b83672
index f369cde408e38962194e7144aec0f4884f232744..9b8773bab6d9c99d3377a1794e80d06d79cb3ede 160000 (submodule)
@@ -1 +1 @@
-Subproject commit f369cde408e38962194e7144aec0f4884f232744
+Subproject commit 9b8773bab6d9c99d3377a1794e80d06d79cb3ede
index 94b960c2618c5249ead14b3e14148df3df0b3e48..857ab85076fb4f30ec8501d1fdf02f7d5b7a20bb 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 94b960c2618c5249ead14b3e14148df3df0b3e48
+Subproject commit 857ab85076fb4f30ec8501d1fdf02f7d5b7a20bb
diff --git a/docs/submodules/openflowplugin b/docs/submodules/openflowplugin
new file mode 160000 (submodule)
index 0000000..e12c7e7
--- /dev/null
@@ -0,0 +1 @@
+Subproject commit e12c7e7216e62c39a42ed26fb72b76db062a62ca
index 204dd82d8da3c296b8a9815d3269f54563916804..1a5e09b4ad24a8ed31cdee66a25e0727f5130fb0 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 204dd82d8da3c296b8a9815d3269f54563916804
+Subproject commit 1a5e09b4ad24a8ed31cdee66a25e0727f5130fb0
index b2e18814e1bdb0c40758f5b0ec9fcdca4114c1b7..ad3143474a1fff2f70d4a4068451488dd9cc0357 160000 (submodule)
@@ -1 +1 @@
-Subproject commit b2e18814e1bdb0c40758f5b0ec9fcdca4114c1b7
+Subproject commit ad3143474a1fff2f70d4a4068451488dd9cc0357
index 6d21d1142684df11dfe15d926c60e4486bae0280..4996d8f8220a161a4dc6d3bc0b2f7072b2827721 160000 (submodule)
@@ -1 +1 @@
-Subproject commit 6d21d1142684df11dfe15d926c60e4486bae0280
+Subproject commit 4996d8f8220a161a4dc6d3bc0b2f7072b2827721
index 5153494111add81a13c3582d56d240ce782e63ec..c01b43a47bb348ad04810a45a2c4f400d6f210d8 100644 (file)
@@ -536,7 +536,7 @@ with optional input parameters:
    --local_address <address> (optional, default 127.0.0.1)
       The IPv4 address where BMP mock is bind to.
 
-   -ra <IP_ADDRESS:PORT,...>, --remoteAddress <IP_ADDRESS:PORT,...>
+   -ra <IP_ADDRESS:PORT,...>, --remote_address <IP_ADDRESS:PORT,...>
       A list of IP addresses of BMP monitoring station, by default 127.0.0.1:12345.
 
    --passive (optional, not present by default)
index 307de691444779efdeda065d9f5e98791ef1bfc8..c8c9ecb5e86ea0437234745f6a12ac9fb44f1db9 100644 (file)
@@ -4364,7 +4364,7 @@ BGP Neighbor Operational State
 
 .. note:: Supported Capabilities only provided when session has been established.
 
-**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbor/127.0.0.2/state``
+**URL:** ``/restconf/operational/openconfig-network-instance:network-instances/network-instance/global-bgp/openconfig-network-instance:protocols/protocol/openconfig-policy-types:BGP/bgp-example/bgp/neighbors/neighbor/127.0.0.2/state``
 
 **Method:** ``GET``
 
@@ -5142,7 +5142,7 @@ with optional input parameters:
    -sc <N>, --speakersCount <N>
       Number of simulated BGP speakers, when creating each speaker, uses incremented local-address for binding, by default 0.
 
-   -ra <IP_ADDRESS:PORT,...>, --remoteAddress <IP_ADDRESS:PORT,...>
+   -ra <IP_ADDRESS:PORT,...>, --remote-address <IP_ADDRESS:PORT,...>
       A list of IP addresses of remote BGP peers, that the tool can accept or initiate connect to that address (based on the mode), by default 192.0.2.2:1790.
 
    -la <IP_ADDRESS:PORT>, --localAddress <IP_ADDRESS:PORT>
index 700c4ea280b0694d13c1626919d374127cdbcefa..53bb1373149086ebf429f71b64fd86766d0ab0ad 100644 (file)
@@ -54,8 +54,9 @@ Project-specific User Guides
    openflow-plugin-project-user-guide
    opflex-agent-ovs-user-guide
    ovsdb-user-guide
-   pcep-user-guide
+   p4plugin-user-guide
    packetcable-user-guide
+   pcep-user-guide
    service-function-chaining
    snmp-plugin-user-guide
    snmp4sdn-user-guide
diff --git a/docs/user-guide/p4plugin-user-guide.rst b/docs/user-guide/p4plugin-user-guide.rst
new file mode 100644 (file)
index 0000000..a4bdd2f
--- /dev/null
@@ -0,0 +1,58 @@
+.. _p4plugin-user-guide:
+
+P4 Plugin User Guide
+====================
+
+Overview
+--------
+
+P4 is a high-level language for expressing how packets are processed by the pipeline
+of a network forwarding element such as a switch, network processing units, software
+switches (bmv2), etc. P4 itself is protocol independent but allows for the expression
+of forwarding plane protocols. It is based upon an abstract forwarding model called PISA
+(Protocol Independent Switch Architecture). In the Oxygen release, the P4 Plugin project
+is aimed to provide basic functions for P4 targets, such as channel and device management,
+table population, packet-in and packet-out process, etc.
+
+
+P4 Plugin User-Facing Features
+------------------------------
+-  **odl-p4plugin-all**
+
+   -  This feature contains all other features/bundles of P4 Plugin project. If you
+      install it, it provides all functions that the P4 Plugin project can support.
+
+-  **odl-p4plugin-core**
+
+   -  This feature provides a function which implements a gRPC client that provides RPCs
+      for users, such as setting and retrieving forwarding pipeline config dynamically,
+      complete table entry population entry and packet out procedures, etc.
+
+-  **odl-p4plugin-netconf-adapter**
+
+   -  This feature mainly provides function about collecting device resource.
+
+
+How To Start
+-------------
+
+Preparing for Installation
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+1. Forwarding devices must support NETCONF, so that OpenDaylight can connect to them
+   and collect resoures via NETCONF.
+
+2. Forwarding devices must support gRpc and run P4 program, so that OpenDaylight
+   can set the forwarding pipeline config, complete table entry population and packet
+   in/out procedure, etc.
+
+
+
+Installation Feature
+~~~~~~~~~~~~~~~~~~~~
+
+Run OpenDaylight and install P4 Plugin Service *odl-p4plugin-all* as shown below:
+
+   feature:install odl-p4plugin-all
+
+For a more detailed overview of the P4 Plugin, see the :ref:`p4plugin-dev-guide`.