Page Comparison

Project Name:

• Proposed name for the project: ONAP Parser Common Service
• Proposed name for the repository: ParserService

Project description:

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

...

• 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

Image RemovedImage Added 

“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 -

Image RemovedImage Added

• 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.

Image RemovedImage Added

“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

Image RemovedImage Added

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

Image Removed

High Level Stories: Externalization

Image Removed

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

...

Architecture Improvisation

Image Added

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

Image Added 

Sequence Diagrams

Centralisation

Image Added

Externalization

Image Added

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

Image Added

High Level Stories: Externalization

Image Added

Detailed Deliverables:

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