Background :
- Proposal for Release 2 / Beijing from Vodafone on Centralization of Parser / Parser As A Service
- Various projects in ONAP are using different Parsers for either model design (en-coding) or model de-coding
- The same function is being performed at many places and there is no consistency in Parser Approach across projects
- Vodafone's proposal is to centralize the Parser as part of Common Services Layer or Modelling Project and expose that As-A-Service
- Which This will bring consistency in Parsing function within ONAP and paves the way for an ultimate model driven stack
- This also opens up the platform implementation approach for Parsers and provide a placeholder within ONAP for a "Parser Surgery"
- This common placeholder can be used to on-board multiple parsers "Multiple Parsers" while retaining the parser exposure to consumers (design/runtime components or even external components in future) via an abstracted "unified / common" API
- Another Another proposal from ZTE on the same concept, "Parser As A Service" was received with a proposal for taking this up in R2 delivery, with OPNFV parser for VFC Component
- It is a similar parser idea, which Almost the same Paerser idea was received from ZTE along with another proposal for a centralized / platform based Run Time Catalogue by ZTE Central RTC has been "tentatively" approved as a new project
- ZTE has given even greater given more details of the proposed architecture and how the common / central parser as a service would look like
- SDC team presented with an idea of exposing SDC parser as a service, proposal was to do a pilot / PoC in R2 for exposing SDC Parser As A Service from SDC project itself
Proposal As Part of 9th January 2018 Modelling Subcommitte Call : Atul.Purohit1@vodafone.com to conduct a series a series of calls with different stakeholders to identify the right approach and put up a consolidated proposal for R2/R3 PoC , potentially going into R3 via a PoC / trial / adoption and route and bring to modelling sub-committe for consideration. The same was noted here : Modeling sub-committee meetings#committeemeetings-20180109MeetingAgenda&Minutes
Meeting / Call notes for from 16th Janury 2018 :
Attendees : denglingli@chinamobile.com (China Mobile), s.shenbaga.rajan@ericsson.com (E///), denghui12@huawei.com (Huawei), zhang.maopeng1@zte.com.cn (ZTE), soareluna@gmail.com (E///), rittwik.jana@gmail.com (AT&T), shang.xiaodong@zte.com.cn (ZTE), Atul.Purohit1@Vodafone.com (Vodafone)
Could Not Join : ml636r@intl.att.com (AT&T)
For Information : Present Release 2 Approved Requirements : Beijing Functional Requirements
Current Parser Distribution in ONAP :
| ONAP Component / Project | Implemented / Proposed Parser | Notes / Comments |
|---|---|---|
| SDC | SDC Parser Java Parser | |
| SO | ARIA Parser | ARIA Parser is not implemented as such, however it is used as an abstraction for HEAT templates representation reuqired by VFC for VNF implementations (in R1) Proposal is to use ARIA parser in SO, but the same has not yet been approved or accepted |
| Multi-EDGE Cloud Solution | ARIA Parser | R2 proposal is to use ARIA Parser |
| VFC | OPNFV Parser | R2 proposal is to externalize this OPNFV parser into "Modelling Project" and expose this "As A Service" |
| UUI | javatoscachecker | Implemented in R1 as an implementation within "Modelling Project" and the only consumer is UUI as of R1 |
| OOM | ARIA Parser |
Points Discussed :
- Defined problem statement to have a common understanding
- There is a need to have a common / central parser within ONAP, definition of common is where more than one component uses the same Parser Implementation
- Use of TOSCA happens at two places, (a) For defining the service models in a declarative fashion and (b) Within components for orchestration in a declarative fashion
- In an ideal world if the service models were common and every component could do orchestration and fulfilment in a declarative fashion, there would be no need to have two levels of implementations
- However TOSCA is so generic that there is a need to have custom changes / extensions in TOSCA
- Stateless approach is not easily feasible in TOSCA context
- Core sapabilities of the parser(s) themselves, they are not equally capable and hence the need to have extensions at individual component level
- While everyone agrees that a central Parser As a Service is a great idea, but what should be the extent of central exposed capability has to be decided and when it comes to consumers of this capability, should the consuming systems negotiate that capability and still apply extensions which are local in nature to the component itself ?
- Key theme / learnings from UUI tasca parser implementation is "Exception Handling",
for example,
Some parsers can parse only sample yaml profile 1.1 or 1.0 or both versions,
Dependein on client (who is implementing the parser capability) there is a need to discuss and decide an Error report (format), errors can occur at different phases - some stops the parsing at the very first step, components do not take automatic corrections because they do not contain the overall service intent
If we build compatible representation of output VID - run time view of what is running where, app-c has run time visibility, 4 components have different UI Unification story in SDC JASON error report, standardize representation not the outut How far are you going to parse if there is an exception any mix of 1.0 or 1.1 document, build extentions and mix them in implementation