17:04:36 <KLuehrs> #startmeeting LSOAPI
17:04:36 <collabot> Meeting started Thu Jan 28 17:04:36 2016 UTC.  The chair is KLuehrs. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:36 <collabot> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:04:36 <collabot> The meeting name has been set to 'lsoapi'
17:04:44 <KLuehrs> #chair KLuehrs
17:04:44 <collabot> Current chairs: KLuehrs
17:04:59 <KLuehrs> #topic Sunset LSOAPI Project
17:08:32 <KLuehrs> #info The objective of this meeting is to announce the termination - or at least suspension - of the Connectivity Services LSO API project in OPNFV.
17:09:06 <KLuehrs> #info Multiple reasons for the decisions follow:
17:10:26 <KLuehrs> #info: (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.
17:12:16 <KLuehrs> #info (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.
17:14:22 <KLuehrs> #info (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
17:14:22 <KLuehrs> as it will be included in ODL Boron release version of UNI Manager.
17:15:46 <KLuehrs> #info (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.
17:17:12 <KLuehrs> #info As a consequence the Connectivity Services LSO API project is terminated (or suspended) effective as of today. No further project meetings are scheduled.
17:19:34 <KLuehrs> Hi Trevor. Did you intend to join the Connectivity Services LSO API project?
17:28:49 <KLuehrs> #topic Project Summary and Wrap Up
17:30:30 <KLuehrs> #info 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.
17:34:46 <KLuehrs> #info 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
17:34:47 <KLuehrs> in two locations:
17:36:26 <KLuehrs> #info 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.
17:39:46 <KLuehrs> #info 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
17:39:46 <KLuehrs> to implementing APIs outside of OpenDaylight as LSOAPI does.
17:42:57 <KLuehrs> #info 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.
17:43:02 <KLuehrs> #endmeeting