#opnfv-meeting: LSOAPI

Meeting summary

1. Sunset LSOAPI Project (KLuehrs, 17:04:59)
   1. The objective of this meeting is to announce the termination - or at least suspension - of the Connectivity Services LSO API project in OPNFV. (KLuehrs, 17:08:32)
   2. Multiple reasons for the decisions follow: (KLuehrs, 17:09:06)
   3. : (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 objectives do not align with Brahmaputra. (KLuehrs, 17:10:26)
   4. (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. (KLuehrs, 17:12:16)
   5. (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 supercede 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 (KLuehrs, 17:14:22)
   6. (4) OPNFV requirements for projects to be included in the Brahmaputra release include executing project code on a instance of OPNFV Pharos release, and this presents a challenge that has so far proven intractable to the LSOAPI project due to lack of appropriate skill set to make this happen. (KLuehrs, 17:15:46)
   7. As a consequence the Connectivity Services LSO API project is terminated (or suspended) effective as of today. No further project meetings are scheduled. (KLuehrs, 17:17:12)
   
   
2. Project Summary and Wrap Up (KLuehrs, 17:28:49)
   1. The OPNFV Connectivity Services LSO projects was initiated to provide a 'home' for API implementations providing the service-level interface, between a business services configuration application and the OpenDaylight UNI Manager plug-in which provides the resource-layer interface to networked equipment to be configured to provide business services. (KLuehrs, 17:30:30)
   2. The project developed API implementations listed below, and tested and validated them on demo/proof-of-concept platform comprised of an Ubuntu Linux PC emulating a cloud-based controller service, two Raspberry Pis running Open vSwitch emulating the customer premise equipment providing User Network Interface (UNI) functionality, and two laptop PCs emulating the customer's network (KLuehrs, 17:34:46)
   3. The API implementations implemented are (1) Services Manager API, (2) EVC Manager API and (3) Class of Service Manager API. The code implementing these APIs has been posted to the LSOAPI project Git repository. (KLuehrs, 17:36:26)
   4. As the companion project in OpenDaylight (UNI Manager) evolved YANG models implementing the MEF Service Layer and the MEF Resource Layer became available. The feasibility of implementing both Service Layer functionalty and Resource Layer functionality in OpenDaylight by integrating the two YANG models provides opportunity for a more feature-complete and integrated solution, compared (KLuehrs, 17:39:46)
   5. The LSOAPI project has followed a natural course of defining an objective, delivering against the objective, then having other more feasible options arise. The project has not seen active participation outside the project initiators and no interest shown by others in taking up the project so the next logical step of the project lifecycle is to terminate it. (KLuehrs, 17:42:57)

Action items

1. (none)

People present (lines said)

1. KLuehrs (21)
2. collabot (4)