meetings:lsoapi
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
meetings:lsoapi [2016/01/07 16:48] Kevin Luehrs |
meetings:lsoapi [2016/01/28 18:13] (current) Kevin Luehrs [January 20, 2016] |
||
|---|---|---|---|
| Line 16: | Line 16: | ||
| ---- | ---- | ||
| - | ====January 6, 2016==== | + | ====January 28, 2016==== |
| + | |||
| + | ===Agenda=== | ||
| + | *Sunset LSOAPI project in OPNFV | ||
| + | |||
| + | ===Meeting Minutes=== | ||
| + | Project management announced the termination of this project. Details are available in the meeting minutes accessed via the links below. | ||
| + | |||
| + | Minutes: http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-01-28-17.04.html \\ | ||
| + | Minutes (text): http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-01-28-17.04.txt \\ | ||
| + | Log: http://ircbot.wl.linuxfoundation.org/meetings/opnfv-meeting/2016/opnfv-meeting.2016-01-28-17.04.log.html | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | ====January 21, 2016==== | ||
| + | |||
| + | ===Agenda=== | ||
| + | *TBD - no topics currently identified. If none then this meeting will be cancelled. | ||
| + | |||
| + | ===Meeting Minutes=== | ||
| + | Meeting was cancelled | ||
| + | ---- | ||
| + | |||
| + | ====January 14, 2016==== | ||
| + | |||
| + | ===Agenda=== | ||
| + | *Evolution of LSOAPI: \\ | ||
| + | -Use case for model-driven - based Service Layer \\ | ||
| + | -Review list of APIs generated by Service Layer YANG modules & identify the methods needed \\ | ||
| + | * Brahmaputra release work items | ||
| + | |||
| + | ===Meeting Minutes=== | ||
| + | * Kevin reviewed the current LSOAPI - UNI Manager architecture then shared plans for using comprehensive MEF-compliant Service Layer and Resource Layer YANG models to create a new version of OpenDaylight UNI Manager plug-in for the OpenDaylight Boron release. \\ | ||
| + | * APIs created by OpenDaylight YANGTOOLS from the MEF compliant Service Layer YANG model were shown for example. \\ | ||
| + | * Kevin said the team is currently updating the LSOAPI - UNI Manager proof of concept/demo to show at CableLabs 2016 Winter Conference Feb. 10 - 12. Mufaddal shared a preliminary map application for the demo. \\ | ||
| + | * LSOAPI code is checked in to the OPNFV LSOAPI project repository for the Brahmaputra release. We still need to complete some tasks for the code to be included in the release including running the code on a PHAROS installation, document a 'scenario' or test plan, and provide scripts for installing the LSOAPI run time environment. | ||
| + | |||
| + | ---- | ||
| + | |||
| + | |||
| + | ====January 7, 2016==== | ||
| ===Agenda=== | ===Agenda=== | ||
| *Status of LSOAPI for Brahmaputra release \\ | *Status of LSOAPI for Brahmaputra release \\ | ||
| *Next steps: MEF service level functionality in OpenDaylight | *Next steps: MEF service level functionality in OpenDaylight | ||
| + | |||
| + | ===Meeting Minutes=== | ||
| + | Kevin reviewed the status of the OPNFV Brahmaputra release and provided a preview of the next steps for the LSOAPI project. | ||
| + | |||
| + | Code freeze for the OPNFV Brahmaputra release was yesterday. Code from this project (Connectivity Services LSO / LSOAPI) is in the project Git repository ready to be included in the release. The Brahmaputra release of OPNFV is scheduled to occur February 2. The LSOAPI code won’t be useful in the Brahmaputra release because LSOAPI calls the OpenDaylight UNI Manager plug-in, which won’t be in OpenDaylight until the Beryllium release, which is also scheduled for February. OPNFV Brahmaputra bundles the Opendaylight Lithium release (prior to Beryllium), so the UNI Manager plug-in won’t be in it. But at least the LSOAPI code will be a “foot in the door” in the OPNFV open source software. | ||
| + | |||
| + | The next step for the LSOAPI project is to create MEF service-level APIs derived from a Service Level YANG model. OpenDaylight’s ‘YANGTOOLS’ utility converts YANG modules to Configuration Data Tree and Operational Data Tree and ‘stub’ APIs. From this framework code can be added to handle service requests made to the data trees through the northbound application interface and pass the requests to the MEF Resource Layer which in turn configure network equipment appropriately. | ||
| + | |||
| + | Kevin shared via the web conference screen sharing utility the APIs created by OpenDaylight YANGTOOLS utility from a Service Level YANG model derived from MEF service layer specifications. | ||
| + | |||
| + | A lot of work remains to be done to create a working Service-level implementation, even a basic proof-of-concept, and the same for the Resource-level. To start with we need to define the initial use case, select which of the methods are required for the initial use case, define the architecture, and develop the Java “listener” code to handle the service requests. | ||
| + | |||
| + | Kevin issued again a call for participation. Intraway hopes to be able to provide development resources. | ||
| + | |||
| + | Kevin took the action to draft a use case for next week’s OPNFV LSOAPI project call. | ||
| ---- | ---- | ||
meetings/lsoapi.1452185284.txt.gz · Last modified: 2016/01/07 16:48 by Kevin Luehrs
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: Creative Commons Attribution 4.0 International License
