Differences

This shows you the differences between two versions of the page.

--- lsoapi [2015/08/13 07:35]
Kevin Luehrs [Key Project Facts]
+++ lsoapi [2016/02/16 20:16] (current)
Kevin Luehrs [Project: Connectivity Services LSO]
@@ Line 1: / Line 1: @@
 ===== Project: Connectivity Services LSO =====
+===February 16, 2016===
+OPNFV TSC approved terminating Connectivity Services LSO project: \\
+http://meetbot.opnfv.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-02-16-14.59.html
+----
+=====Project Termination Request=====
+**February 1, 2016**
+The Connectivity Services LSO project petitions OPNFV Technical Steering Committee to terminate the project in OPNFV.
+__Reasons for Termination Being Sought__ \\
+The reasons for termination being sought are detailed in project meeting minutes for the January 28 project meeting and summarized below.  Reference:  http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-01-28-17.04.html
+(1) Brahmaputra release is focused on the data center and not on providing services to the network or customer CPEs. The LSOAPI project is specifically about providing business services to service provider customers on the network, so project objectives do not align with Brahmaputra. \\
+(2) LSOAPI uses services of OpenDaylight UNI Manager plug-in, which will be introduced with the Beryllium release (Feb. 2016). However OPNFV Brahmaputra will integrate ODL Lithium release (June 2015) which does not include UNI Mgr plug-in so in Brahmaputra LSOAPI will not a supporting ODL functionality and will therefore provide little to no value. \\
+(3) In the ODL UNI Manager project current plans are to evolve the plug-in to incorporate Service Layer YANG model and Resource Layer YANG model. This will supersede and obsolete the 'basic' Service Layer functionality currently being provided by LSOAPI. That is, if the current plan for UNI Manager comes to fruition, LSOAPI will not be needed to provide Service Layer functionality as it will be replaced with more complete Service Layer functionality in OpenDaylight. \\
+(4) OPNFV requirements for projects to be included in the Brahmaputra release include executing project code on an instance of OPNFV Pharos release and include LSOAPI testing in Brahmaputra continuous integration environment. This presents a challenge that has so far proven intractable to the LSOAPI project due to lack of access to appropriate Pharos resource  and to lack of appropriate resource familiar with Brahmaputra CI environment. \\
+Note: The requirement for Service Layer functionality that LSOAPI provides for the initial proof-of-concept for configuration of Carrier Ethernet services using open source controller platform does not go away. Our vision is it will migrate to a more full-featured implementation in OpenDaylight. So while the LSOAPI project is terminated the function it was initially created to provide could be implemented in OpenDaylight and incorporated in OPNFV indirectly, as part of OpenDaylight.
+__Estimated Impact on Other OPNFV Projects__ \\
+LSOAPI API implementations provide an application that uses the OPNFV framework rather than serving as part of the framework. Therefore terminating the LSOAPI project is not expected to have any impact on other OPNFV projects. Removing LSOAPI removes the preliminary Service Layer for the Carrier Ethernet service provisioning application that uses OpenDaylight UNI Manager project as the Resource Layer (element management system), but the new vision is to implement both the Service Layer and Resource Layer in OpenDaylight.
+__Impact on Reference Platform Builds__  \\
+LSOAPI is not part of the OPNFV reference platform so terminating it is not expected to have an impact on OPNFV Reference Platform Builds.
 ===== Project Description: =====
@@ Line 41: / Line 68: @@
 An initial UML representation of the EPL information model based on MEF Technical Specification 7.2 Carrier Ethernet Management Information Model is shown in Figure 3. The project will develop UML and YANG versions of the model and evolve them as MEF specifications evolve. The data model will be used as reference for development of the MEF APIs.
-{{ :mef_classes.png?600 |}}
+{{ :mef-classes_preliminary.png?600 |}}
 Figure 3 Ethernet Private Line Service Initial Information Model
@@ Line 48: / Line 75: @@
   * Project proposal page: https://wiki.opnfv.org/lar-e
   * Meeting minutes:  https://wiki.opnfv.org/meetings/lsoapi
+  * Project repository:
+      *<nowiki> git clone ssh://<your opnfv id>@gerrit.opnfv.org:29418/lsoapi  </nowiki> \\
+      * git clone https://gerrit.opnfv.org/gerrit/lsoapi \\
-==== Key Project Facts ====
+====Key Project Facts====
 **Project:** Connectivity Services LSO (lsoapi)\\
@@ Line 57: / Line 87: @@
 **Primary Contact:** Kevin Luehrs, CableLabs (k.luehrs@cablelabs.com) \\
 **Project Lead:** Kevin Luehrs\\
-**Jira Project Name:** Connectivity Services LSO \\
+**Jira Project Name:** Connectivity Services LSO \\
+https://jira.opnfv.org/browse/LSOAPI/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel \\
 **Mailing list tag: ** [lsoapi] \\
 **Jira Project Prefix:** (lsoapi) \\
@@ Line 86: / Line 117: @@
 Requirements document: https://wiki.opnfv.org/lsoapi/documents/Requirements
 **Documents**
 https://wiki.opnfv.org/lsoapi/documents

Wiki

User Tools

Site Tools

Differences

Page Tools