Project Name:
- Proposed name for the project: ONAP Parser Common Service
- Proposed name for the repository: ParserService
Project description:
Preface:
- A clear separation of “Design Time” and “Run Time” execution platforms with in ONAP gives an opportunity to truly model drive the run time execution platforms from the design time modelling platform.
- On the Design Front : Various developments in R1 of ONAP’s SDC and SO (MSO) modules have provided a ground for defining a logically centralized reference platform for designs & models using multitude of design patterns & grammar, it in-effect proposes a placeholder for future evolution of ONAP to truly model drive ONAP
- On the Run Time Front : R1 proposes a Run Time Catalogue embedded within each Execution Platform with certain common set of functionalities that can be centralized (in model driven architecture spirit) and eventually externalized for triggering business cases for much better interop between non-ONAP and ONAP based B/OSS stacks in various service providers
- This proposal is an evolutionary idea to further the model driven concept and it also suggests an even greater inter-op construct with non-ONAP Service Provider B/OSS stacks for a global ONAP and truly model driven stack adoption & evolution
- At a high level, this proposal is achieved in 2 stages (a) Centralization and (b) Externalization of Parser Binaries
Idea:
- As part of R2, we are proposing an improvisation of parser implementation function under the “Centralization of Parser” part of the proposal
- current Understanding of Parser Implementation (as part of Design / Run time catalogue) are as below –
A model creation UI (model designer) as part of “Design Time Catalogue”
- 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)
- Commissioned Report Results on Parser Usage and Preference By (some) Participants of a Survey Earlier in December 2017
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 binaries which will be used for de-coding are being built into the “Runtime Catalogue” of Service Orchestration platform
Run Time Catalogue will have two functions (i) Model De-Coding and (ii) Object Translation / Formation
Current R2 proposal is for Run Time Catalogue to be replicated for each execution platform, starting with Service Orchestration (MSO)
Our Proposal is to pluck the “Model De-Coding” aspects of the Run-time Catalogue and build that as part of the Common Services Platform as part of the “Centralization of the Parser” theme
“Common Services Platform” Implementation – Consolidated logic, as mentioned in steps 2 and 3 in above diagrams should be implemented in common service layer
- 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
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 Story: Centralization
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 |