Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

STATUS: Draft

RunTime DB:

1 High Level Component Definition and Architectural Relationships 



The RunTime DB function provides storage for real-time run-time parameters that need to be used by ONAP. It provides

PURPOSE:

  • REPOSITORY -  The types of data that is stored in the Run-Time data storage repository for: (1) configuration parameters used by xNFs in run time and (2) operational parameters used by ONAP and xNFs.

  • DATA LAKE - It is designed to be a common services data layer which can serve as a data lake.
  • SYNCING - The RunTime DB enables the ability to sync data between ONAP & the xNFs. (The source of truth can be define).
  • CM FUNCTIONS - Enables OSS configuration, optimization, and LCM operations. (FUTURE)
  • CM FUNCTIONS - Enables future CM & Data management functions such as xNF Crash restoration, data restoration, data history management and auditing. (FUTURE)
  • CENTRAL/DISTRIBUTED - Because it is a common service, it is part of an ONAP installation, so it could be deployed with either an Edge ONAP installation or a centralized ONAP installation. (FUTURE)
  • SCOPE - The Run Time DB could also serve as the data storage to store for example ONAP Policy Rules, CLAMP Control Loop, Operational Views (FUTURE)

ACCESS (READ/WRITE):

  • READ ONLY - Run-Time parameters can be READ by any ONAP platform component and any ONAP plug-in. Examples of ONAP platform components are A&AI, SDC, SDNC etc.
  • READ/WRITE - Parameters can be READ/WRITE from Controllers, DCAE (future), VES Collector/DMaaP, A&AI, Policy/CLAMP (future) and other components with permission settings.

  • DEFAULT - SO (future), DCAE, A&AI, Controllers (CDS, APPC, SDNC) will have default read/write access to RunTime DB
  • DEFINABLE - Other components will have default read-only access to RunTime DB but can be given Read/Write access on a per record basis.

SYNCING (INVENTORY):

  • ELEMENT SYNC - Software keeps the A&AI elements with the elements in the RunTime DB in Sync. 

  • A&AI - A&AI is still the master of valid entities in the network and provides a dynamic view of the assets (xNFs) available to ONAP
  • RUNTIME DB - The RunTime DB is a master of the associate (exo-inventory) data associated with the entities.
  • DYNAMIC VIEW - When a xNF appears or is removed from the system, RunTime DB records will be added/removed based on A&AI entries.

INDEXING:

  • INDEXING - Data Records will be indexed by xNF (VNF, PNF, ANF).
  • RETRIEVAL - How are data records retrieved efficiently. This relates how the records are indexed.

2. API definitions

RunTime DB provides the following interfaces:

Interface NameInterface Definition Interface CapabilitiesVersionStatusConsumed Models
RTDBE-1RunTime DB Interface. 

An interface to create, update, retrieve, query, delete information from the RunTime DB.

ACCESS:

 - SO, DCAE, A&AI, Controllers (CDS, APPC, SDNC) will have default read/write access to RunTime DB

 - Other components will have default read-only access to RunTime DB but can be given access on a per record basis.




RTDBE-2RunTime DB Graphical User Interfaces Provides the capability to view and edit the data currently in the RunTime DB.


Note:   xxxI interface is a Component internal interface.  xxxxE interface is a component external interface

The current API documents can be found at:

RTDB consumes the following Interfaces:

Interface NamePurpose Reason For Use
SDCE-7

To receive the service and resource artifacts from SDC.

STEPS:

(1) ONBOARDING - A vendor onboards artifacts describing the parameters supported for their PNFs and VNFs.

(2) SDC CATALOG - The onboarded artifacts are stored in the SDC Catalog after onboarding and validated (VNF-SDK).

(3) CSAR DISTRIBUTION - The contents of the artifacts are distributed by SDC in a CSAR package onto the DMaaP bus.

(4) SETTING UP RUNTIME DB - S/W to setup the RunTime using the content of the CSAR package consumes the SDC CSAR Package.


3. Component Description:

A more detailed figure and description of the component.


4. Known system limitations


5. Used Models

RunTime DB uses the following models:

  • Inventory Model


6. System Deployment Architecture



7. New Capabilities in this Release

This release, RunTime DB adds the following Capabilities:

  • -

8. References

  1.  
  • No labels