Problem Resolved:roblem Resolved
...
SDC now support the VNF package onboard, and NS design. After the VNF package onboard and design, the packages will be categorized and put into the SDC catalog. SDC catalog also supports the package status of design time, such as check in/ check out/ in design/Ready for testing/in testing/Certified/distributed.
- vRun-Time in R1
In Run-Time, there exists template and recipes, workflows of different levels such as service/NS/resources in different components(SO, VFC, SDNC, APPC, Policy, …). SO consumes service template, VFC consumes network service and VNF template, policy consumes service/network/VNF rule recipes and so on.
- Lack of unified catalog management in the Run-Time
In the Run-Time, it is hard to manage the catalog in a unified way among the different levels and runtime instances.
- Unified Model API
Now many Run-Time components use different parser, and do some repeat works. The Run-Time catalog will also consider the unified models API based on the design template, exposed to all Run-Time components, reducing the complex and repeatable parser work. Table of Contents outline true
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: RT-Catalog rtc
Project description:
The ONAP RT-Catalog project aims to provide unified catalog management in ONAP runtime environment, including service, service component, and resource levels.
Scope:
•Levels:
•Service level:
Service catalog (templates, workflow, recipes, ……)
•Service Component level:
NS catalog (templates, workflow, recipes, ……), WAN catalog (templates, workflow,….)
•Resource level:
VNF catalog(VNF image, templates, scripts, recipes,……), PNF catalog(….)
•Functions:
- Provide all level catalog management, including design time catalog synchronization, upload, enable, disable, update, delete catalog item in the Run-Time
- provide the catalog relation management among the different levels and different components
- Provide the catalog status management in the run-time, such as IN_USE, NOT_IN_USE, ENABLED, DISABLED, etc
- Provide the API to fetch the packages or files in the catalog, including the external system, and inner components
- Provide the API to consume the descriptor parser result, reducing the package download time consuming between the different components.
Architecture Alignment:
...
.
- Problem Resolved
- Benefits
- Separation of concerns – Model Design vs. Runtime Using
- Simplification of Design time to Runtime model distribution
- Flexibility by allowing runtime component’s self-define model view & data subscription
- Consolidation of Runtime Data storage and management
Scope:
Management Objects:
All Certified Design Model
Consistent definitions with SDC Design Catalog
Functions:
Provide RT-catalog GUI, storage and management functions, including CRUD, distribution, synchronization, enable, disable, etc
- Provide RT-catalog view distribution for RT component, including RT component self-composed views, subscriptions, and data access
- Provide RT-catalog data status & Tracking
- Provide search capacity for fast access across run-time catalog data
- Provide portal for the Human Interface
- Provide S3P related capacity for RT-Catalog
Architecture Alignment:
RT-Catalog architecture
RT-Catalog Storage
What other ONAP projects does this project depend on?
- SDC(DT-Catalog)
- Multi-VIM
- AAI/ESR
- MSB/DMaaP
- Model
- OOM
- Integration
- RT-Components(UI\SO\VFC\APPC\Policy\.......)
- Common service(MSB/DMaaP/Parser.....)
How does this align with external standards/specifications?
- APIs/Interfaces - OpenAPI/Swagger, ETSI NFVREST/PubSub
- Information/data models - Swagger JSON
Are there dependencies with other open source projects?
- APIs/Interfaces - mysql, DjangoInterfaces
- 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
...
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:
...
Role | First Name Last Name | Linux Foundation ID | Email Address | Location | |
---|---|---|---|---|---|
Role | First Name Last Name | Linux Foundation ID | Email Address | Location | |
PTL | CommittersAGRAHARAM,SANJAY | sa2785@att.comMaopeng Zhang | zhang.maopeng1@zte.com.cn | Beijing, China. UTC +8 | |
Committers | Fengyuanxing | Beijing, China. UTC +8 | |||
Yueliang Liu | Beijing, China. UTC +8 | ||||
Zhanjie | zhang.jie1@zte.com.cn | 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 |