...
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 among teams
- General Agreement was that there There is a need to have a common / central parser within parser placeholder 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 by individual implementations to extract full set of functionality by the implementing component
- Stateless approach is not easily feasible in TOSCA context
- Core sapabilities capabilities of the parser(s) themselves, they are not equally capable and hence the need to have extensions at individual component level (Core Capabilities of Parser comes from if the parser is based on Sample YAML profile 1.0 or 1.1 or 1.2)
- 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 (along with a governance model) 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 ? or should everytime an implementation component proposed extensions, they should be subsumed in central Parser Placeholder and be exposed as a service
- 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 Depending on client (who the component which is implementing the parser capability) there is a need to discuss and decide an Error/Exception report (format), errors Errors/Exceptions can occur at different phases - some components (execution platforms) stops the parsing at the very first step, components some execution platforms (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 four 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 (Serben to share his UUI implementation experience / challenges / learnings) - So far, three TOSCA based parsers are submitted to "Modelling Project", each having a variation in Parser Defintion and the API to access them is also different, details are here Modeling API
Excerpt of UUI / javatoscachecker implementation experice (Serben)
What is the Scope of "Parser As A Service" ?
- Does the Parser Contain Well Formed YAML
- Is it Syntactically Correct TOSCA (Grammer to be checked against TOSCA Specifications)
- Coherence Checking (As Much As Possible) : Type Reference / Property Reference etc...
What is the input to Parser ?
- Usually a CSAR Archive File
- Questions :
- Is the CSAR File Self Contained ?
- Are all documents within it, or does the TOSCA parser requires some additional details ? (If we agree that Parser As A Service function is Stateless, there is a need for CSAR to be self-contained)
- If CSAR is a single file, does it contain all necessary specifications ?
- If there is multi-part content representation, should it be with one document or part of it ?
- Observation : The tool should be able to resolve the whole import tree i.e. resolve all dependencies.
- What is the expected output / response of this "Parser As A Service" function ?