Run-Time Catalog
Declined by TSC as a stand-alone project. Recommended as a component of Service Design & Creation Project
Project Name:
• Proposed name for the project: ONAP Runtime Catalog
• Proposed name for the repository: rtc
Project description:
The ONAP RT-Catalog project aims to provide unified catalog management in ONAP runtime environment.
Problem Resolved
Benefits
Scope:
Architecture Alignment:
RT-Catalog architecture
RT-Catalog Storage
What other ONAP projects does this project depend on?
SDC(DT-Catalog)
RT-Components(UI\SO\VFC\APPC\Policy\.......)
Common service(MSB/DMaaP/Parser.....)
How does this align with external standards/specifications?
APIs/Interfaces - REST/PubSub
Information/data models - Swagger JSON
Are there dependencies with other open source projects?
APIs/Interfaces
Integration Testing
etc.
Other Information:
link to seed code (if applicable)
Vendor Neutral
if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
Meets Board policy (including IPR)
Use the above information to create a key project facts section on your project page
Key Project Facts:
Primary contact: zhang.maopeng1@zte.com.cn
Facts | Info |
|---|---|
PTL (first and last name) | Maopeng zhang |
Jira Project Name | Run-Time Catalog |
Jira Key | RTC |
Project ID | rtc |
Link to Wiki Space |
|
Release Components Name:
Note: refer to existing project for details on how to fill out this table
Components Name | Components Repository name | Maven Group ID | Components Description |
|---|---|---|---|
catalog manager | rtc/catalog-manager | org.onap.rtc.catalog-manager | RT-catalog data model management |
catalog distribution | rtc/catalog-distibution | org.onap.rtc.catalog-distibution | RT-catalog data model distribution to RT components |
catalog modelsync | rtc/catalog-sync | org.onap.rtc.catalog-sync | RT-catalog data model synchronization from SDC catalog |
catalog portal | rtc/catalog-portal | org.onap.rtc.catalog-portal | RT-catalog model management and distribution portal for operator |
catalog storage | rtc/catalog-storage | org.onap.rtc.catalog-storage | RT-catalog certified model storage |
Resources committed to the Release:
Note 1: No more than 5 committers per project. Balance the committers list and avoid members representing only one company.
Note 2: It is critical to complete all the information requested, that we help to fast forward the onboarding process.
Role | First Name Last Name | Linux Foundation ID | Email Address | Location |
|---|---|---|---|---|
Role | First Name Last Name | Linux Foundation ID | Email Address | Location |
PTL | Maopeng Zhang |
| Beijing, China. UTC +8 | |
Committers | Fengyuanxing |
| Beijing, China. UTC +8 | |
Yueliang Liu |
| Beijing, China. UTC +8 | ||
Zhanjie |
| Beijing, China. UTC +8 | ||
AGRAHARAM,SANJAY |
| US, EST | ||
David Shadmi |
| CST | ||
Michael Lando |
| Israel | ||
|
|
|
| |
Contributors | Luji |
| Beijing, China. UTC +8 | |
Shijie |
| Beijing, China. UTC +8 | ||
Qidi Lv |
| Beijing, China. UTC +8 | ||
pengpeng |
| peng.peng@zte.com.cn | Beijing, China. UTC +8 | |
Ting Lu |
| US, EST |
Comments
RT-Catalog is different from AAI. AAI focus on the topology & inventory of the ONAP; RT-Catalog focus catalog package related functionalities:
catalog package operation & status consistency
catalog package and instances relationship, including which instances use the package
catalog package version management in the RT
catalog package related query and fetching API for RT components, including ONAP components and external systems
Thank you for the proposal. A few questions:
Today, when packages are sent from SDC-Catalog to runtime, is this done via DMaaP notifications and subscriptions? How does this proposal change that current process?
Please explain the need for two catalogs (SDC and Runtime). Can't we have one catalog and use versioning and states?
Any synergy with the Image Manager proposal?
Q1: SDC supports DMaap message and Restful API. RT-Catalog will both consider it.
Q2: Generally in the model view, design-time is to generate model, and run-time is to consume model.
Now the Design-time SDC has a catalog DB to storage the model data to satisfy the design time requirements, and generate TOSCA files to the RT compnonents when needed.
RT-Catalog consumes the TOSCA files, and provides the TOSCA files management and parsed result for all RT-components, rather than each components do it by itself.
RT-Catalog can provided different specific TOSCA instance models via TOSCA files, different inputs and parser, which are different from the design-time.
Q3: Image is one of the catalog files, RT-catalog can cooperate with the image manager.
Hi Maopeng, while i totally buy the concept of centralization and making some logic available as part of common services - de-duplication is the nirvana we all have to move to. In our proposal on Parser Centralization, I have assumed a slightly different way of achieve model driven centralization. Would you please have a look at
https://lf-onap.atlassian.net/wiki/pages/viewpage.action?pageId=16261871 and comment.
Key points that i am grappling with is the the main function of run time catalogue is to create application specific / consumable objects that can be ingested seamlessly into the run time applications : and every application has a slightly different data model. Hence a centralized RTC means you need to start understanding data model of each application for RTC to make and distribute objects. This is where you start limiting innovation, if we want each application to have a secret sauce or formula of how they want to play with the data, let them create the object. Generalization of Centralization should be done of slightly more abstract constructs like service models, they are just intents / similarly the parser grammar which is again just a high level library of symantics to be used. If we centralize or generalize the run time object formation, than you take away the core data model implementation logic. While this may work in ONAP world, imagine the external system that you may want to drive with this logic, they won't necessarily have same data model as ONAP and by this way - you end up forcing your data model object to them. Provide them intent, provide them grammar - let them work out objects in my huble opinion.
Again totally supporting centralization idea in general.
Thanks / Atul Purohit
Thanks Atul, totally we all support centralization idea in general.
First, generally in the model view, design-time is to generate model, and run-time is to consume model. Now the Design-time SDC has a catalog DB to storage the model data to satisfy the design time requirements, and generate TOSCA files to the RT compnonents when needed. RT-Catalog aims to reduce the duplication in the runtime, provided centralized TOSCA files management and parsed result for all RT-components, rather than each components do it by itself. The RT-Catalog can provided different specific TOSCA instance models via TOSCA files, different inputs and parser, which are different from the design-time.
Second, runtime catalog consumes the parser result and provides the tosca instance model for all the RT-Component based on the TOSCA grammar parsed result, not concerning about "the application specific / consumable objects" as well.
Hi,
Does RT-Catalog act as a wrapper over services provide by AAI? What additional functionality does it provide apart of massaging the data retrived from AAI ?
BR,
Viswa