...
- Proposed name for the project: ONAP Parser Common Service
- Proposed name for the repository: ParserService
| View file | ||||
|---|---|---|---|---|
|
Project description:
Preface:
...
- Below picture depicts the segregation / dissection of parsing function spread across design and run time environments
- Highlighted / Encircled Portion in Red shows functional blocks that Design Time Catalogue covers
“Design Grammar” for creation (En-Coding) of models being proposed using some of the (Apache Foundation / Cloudify Proposed / ONAP Custom / technology focussed) popular and prevalent parser(s)
...
A snapshot of result from the survey as below -
Irrespective of Parser Function that is chosen for implementation in R2 Beijing, idea is to propose “Centralization of Parser” concept as a rather “Centralization of Grammer” function and treat ONAP as a Platform rather than a finished product for use right out of the box (argument in favour is that service providers may want some custom features specific to their preferences, akin to Openstack or Linux or any other Open source porject)
Another part of proposal is to do with “Design time catalogue” function i.e. once the model are built, they are en-coded via one of the parser binary / library / definition, Refer : Picture below
While the ONAP platform may default the Parser Implementation with a certain flavour of Parsing Function Grammer, this “Centralization of Parser” proposal endeavours to provide a choice to service proviers to select any of the parser functions that were proposed in the survey (above) or beyond (in future). Even if there is ONE parser to be used in ONAP, this proposal provides the centralization as opposed to a federated implementation of parser en-coding / de-coding at multiple places.
“Design Grammar” for extrication (de-coding) of models which is proposed has to be the same as the one we used for en-coding in SDC
...
- Parser Definition / Binaries will sit in central common service block as a collection of micro-services in a self-contained block
- By the very definition of this block, common services are applicable for all design and run time components within ONAP and hence this step will de-duplicate multiple en-code / de-code functions and make them central to ONAP blocks
- By adopting this approach, we would have created a placeholder for TOSCA / Parser function binaries and reference definitions
- While this provides central definition / orchestration and control of TOSCA parsers, this implementation also provides a hook into the nest steps of our proposal
Subsequent extensions is the proposed “Externalization of Parser” concept. Acquisition of Parser Binaries / Definition from a central repository which is hosted and maintained by a standard body like Apache Foundation or OASIS or Linux Foundation – We understand that this proposal would require (one or more) SDO engagements and will need a governance around Parser Definition / Distribution & on-going management. However if we ever had a chance to make ONAP and rest of the B/OSS Service Provier stack model driven, perhaps this is it. If we can (a) Centealize Parser (b) Externalize the Reference (c) Build Business Case for Existing B/OSS Stack of CSPs to upgrade and reference same global parser function (d) Work Out the interop, by use of MEF / TMF APIs – that would take us to a truly model driven economy for a service provider across ONAP and non-ONAP stacks
Architecture Improvisation
Points to Note :
- Common theme across design and run time is the use of common TOSCA binaries for en-coding and de-coding
- The object formation function of run time catalogue is specific to the execution platform, since the data model of the application is not common
- Implementation of the run time catalogue can be central or distributed, however the key function of RT catalogue i.e. object formation is tightly coupled with data models of the respective execution platform applications
- Only common thread is the use of binaries / definitions - if an Apache TOSCA parser is to be used, the same has to used at both ends of the modelling spectrum i.e. design and run time
- Hence a common parser grammer placeholder as well as model ↔ parser (function & binary repository) ↔ model conversion is the core part of functionality that can be centralized and this is what parser common service proposal is all about
Sequence Diagrams
Centralisation
Externalization
Overall Scope: High Level Requirements
...
- De-Coupling of Library Requirements of En-Coding Function from SDC / Design Time Catalogue
De-Coupling of Library Requirements of De-Coding Function from MSO / Run Time Catalogue
Creation of TOSCA Parser Binary Placeholder in Common Services Layer
Creation of Consumption / Reference (for the Parser Binaries) Flows from Common Services Layer
Common Services Layer Logic Implementation Using Micro-Service(s) - For orchestrating TOSCA parser binaries
- (Subsequently) Implementation of Binary Acquisition / Updation from External Repository (Dependency on SDO engagement)
- Governance around Parser / Models Function Maintenance
...
High Level Stories: Externalization
Detailed Deliverables:
Activity / Capability | Description | Comments / Notes / Dependency |
Centralization User Story / PAR1 · Creation / Ring-Fencing the Parser En-Coding & De-Coding Function | · The actual En-Coding and De-Coding Logic remains part of the Design time and Run time catalogue · Binary / Definition, which are referenced by these blocks will reside in Common Services Layer, this story will focus on isolating the logic for referencing of parser binaries | · Binary Acquisition Service / API exposed by Common Service Layer needs to be sorted · TOSCA Binary Refresh / Push / Pull Mechanism to be Sorted (on to consumer platforms) |
Centralization User Story / PAR2 · De-Coupling of Ring-Fenced logic from SDC into Common Services Layer | · Once the binary definition placeholder is segregated within catalogues, the same needs to be ported to Common Services Layer | · Implementation of binary hold within Common Service Layer should be via micro-service(s) |
Centralization User Story / PAR3 · Create API / Interface for acquiring Parser Binaries from Common Services Layer | · Common Services Layer needs to expose the binary acquisition via services / APIs in a standard way to (any consumer) platform | · The mechanism is very similar to how catalogue function downloads models on to execution platforms, TMF / MEF needs to be referenced for any suitable API / Generic mechanism to transfer the definitions binary |
Externalization User Story / PAR4 · Modify Parser Container in Common Services Layer to start referencing external SDO via API exposure layer | · Binary / Definition itself will reside external to ONAP, within a globally available repository managed and operated by a SDO · ONAP team has to work with SDO to agree common way of Parser/Repository Governance, Maintenance and Exposure | · Dependency on SDO engagement and governance |
Supplimentry Information
Managed Objects:
- Parser Definition / Binaries
- Worflows, Versioning
- Service Templates and Parsed Template Outputs
Functions:
- TOSCA Parser Binary Management, including synchronization, upload, acquire / distrubute functions
- Integration with OOM or its own UI for Parser Binary Management
- Provide API to fetch / distrubute the binaies to design / run time catalogues, including the external non-ONAP system (via API Gateway), and inner run time ONAP components
Role | Name | Gerrit ID | Company | TimeZone | |
Primary Contact | Atul Purohit |
| Vodafone Group | Newbury, UK, GMT / UTC | |
Committers (Yet to confirm) | Cloudify | ||||
| Amdocs | |||||
NetCracker | |||||
Huawei |
|
|
| ||
Infosys |
| ||||
| E/// |