Run-Time Catalog

Problem Resolved:roblem Resolved

• Design time catalog and the Run-Time catalog are independent management.
  Design time can operate the packages or files, and info the Run-Time components. In the Run-Time catalog also should support to manage the catalog in a unified way.
• Lack of unified catalog management in the Run-Time.
  • In Run-Time,  there exits template and recipes, workflows of different levels such as service/NS/resources in different components(SO, VFC,  SDNC,  APPC, Policy, …).  
  • AAI supports SDC TOPO Schema,  SO supports synchronization data with SDC,  other component almost same with SO. Almost all do not support the independent Run-Time catalog management.
• Further more, the Run-Time catalog will also consider the unified models API based on the design template  to all Run-Time components, reducing the complex and repeatable parser work.

Project Name:

• Proposed name for the project: ONAP Runtime Catalog
• Proposed name for the repository:  RT-Catalog

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, on-boarding, enable, disable, update, delete catalog item in the runtime, etc.
•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:

• How does this project fit into the rest of the ONAP Architecture?
  • Please Include architecture diagram if possible
    
  • What other ONAP projects does this project depend on?
    • SDC
    • Multi-VIM
    • AAI/ESR
    • MSB/DMaaP
    • Model
    • Image Management(proposed)
    • OOM
    • VNFSDK
    • Integration
• How does this align with external standards/specifications?
  • APIs/Interfaces - OpenAPI/Swagger, ETSI NFV
  • Information/data models - Swagger JSON
• Are there dependencies with other open source projects?
  • APIs/Interfaces - mysql, Django
  • 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

Release Components Name:

Note: refer to existing project for details on how to fill out this table

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.