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
      • 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)
  • 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 NameRun-Time Catalog
Jira KeyRTC
Project IDrtc
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 managerrtc/catalog-managerorg.onap.rtc.catalog-managerRT-catalog data model management
catalog distributionrtc/catalog-distibutionorg.onap.rtc.catalog-distibutionRT-catalog data model distribution to RT components
catalog modelsyncrtc/catalog-syncorg.onap.rtc.catalog-syncRT-catalog data model synchronization from SDC catalog
catalog portalrtc/catalog-portalorg.onap.rtc.catalog-portalRT-catalog model management and distribution portal for operator
catalog storagertc/catalog-storageorg.onap.rtc.catalog-storageRT-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

PTLMaopeng Zhang
zhang.maopeng1@zte.com.cnBeijing, China. UTC +8
Committers

Fengyuanxing


feng.yuanxing@zte.com.cn

Beijing, China. UTC +8

Yueliang Liu

liuyueliang@chinamobile.com

Beijing, China. UTC +8

Zhanjie


zhang.jie1@zte.com.cn

Beijing, China. UTC +8

AGRAHARAM,SANJAY


sa2785@att.com

US, EST

David Shadmi


David.shadmi@att.com

CST

Michael Lando


Michael.lando@att.com

Israel





ContributorsLuji

lu.ji3@zte.com.cn

Beijing, China. UTC +8

Shijie


shi.jie3@zte.com.cn

Beijing, China. UTC +8

Qidi Lv

lvqidi@chinamobile.com

Beijing, China. UTC +8
pengpeng
peng.peng@zte.com.cnBeijing, China. UTC +8

Ting Lu


Tingting.lu@att.com

US, EST



  • No labels

15 Comments

  1. Viswanath Kumar Skand Priya

    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

    1. maopeng zhang

      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


  2. Jason Hunt

    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?

    1. maopeng zhang

      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.

  3. Atul Purohit

    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://wiki.onap.org/pages/viewpage.action?pageId=22249726 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

    1. maopeng zhang

      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.



  4. Stephen Terrill

    I suggest to clarifiy:

    • Model onboarding is out of scope (done via SDC)
    • Tracking instantiated services and resources is out of scope (in A&AI).
    • Clarify what "Provide catalog relation management among different ONAP runtime component" really means.  It could be interpreted as tracking the availble of ONAP run-time comonents, but I understand it to mean that "tracking which ONAP component is using which model".

    Then I am wondering what the human interface is to achieve compared to what should be done for catalogue management from the SDC perspective.

    1. maopeng zhang

      1. Agree with onboarding and tracking  instantiated services and resources out of scope.

          2.  Yes, you are right, and I will modify it

          3.   RT-Catalog will support human interface to provide operations:

                   show rt-catalog information and disable, enable, delete package in RT, etc

                   configuration for the RT-catalog, such as auto-sync policy with SDC, etc


      1. Stephen Terrill

        Thanks for the reply.

        Regarding the human interface.  I agree that the design personas and the operational personas would have a different view of the items in the catalogues, with different permissions.  If we look at this from a lifecycle perspective of the models can we clarify what is in what scope.  In the design view we have: onboard; create; modify; test; Deploy (handover to RT - CAT); Undeploy (better name??) and Delete.  in the operational view: I can see enable, disable.  I am not so convinced of delete as then we have "two masters" of the LCM of the model that can lead to inconsistencies.

        1. maopeng zhang

          Now SDC support package distribution to Runtime via pub/sub. Saying in other words, SDC only is in charge of management of design time catalog.  For runtime catalog, when to delete the package is mainly decided by the runtime operator and whether RT-component and instances use it. So I think for the deletion operation will be consider in the runtime catalog as seperation from design time.

          1. Stephen Terrill

            There needs to be sycnronization here with the DT.  In the designtime, it needs to be understood that "model" can no longer used in service or resource design.

            1. maopeng zhang

              There is pub/sub mechanism between the DT and RT. If DT concern the info from RTC, DT can sub the topic and RTC can pub the topic as needed. Furthermore, this feature should be confirmed and discussed with SDC as well.

              Gerneral, RTC will support this message topic pub/sub and let components to consume.

              Thanks for your suggestions.

      2. Stephen Terrill

        Were the updates on the scope clarification done?

        1. maopeng zhang

          Yes, recently I talk with SDC team and RTC supporters, do some changes. The work and cooperation now is done and make agreement. Thanks Steve for your concern.

  5. Chesla Wechsler

    Will the RT-Catalog store the distribution status of the environment it supports, I.e., if you have one SDC feeding more than one environment (test, production, etc.), will the RT-Catalog be the place where one can see whether all run time components within the given environment have successfully received a distribution?  I believe it should.

    Will the RT-Catalog permit any authorized client to pull model metadata assuming the client has the key(s) of the asset it's looking for?

    Will the RT-Catalog be TOSCA aware and able to resolve substitution mappings in a way that it's easy for a client to tell what node types may be candidates to substitute for other nodes?  I could see both SO and other components finding that useful (e.g., AAI doing data validation on instances based on the model).