Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 79

...

  • Proposed name for the project: ConfigPersistencySvc
  • Proposed name for the repository: ConfigPersistencySvc
  • Project Logo:

Image RemovedImage Added

PROJECT DESCRIPTION

...

  • REPOSITORY -  The types of data that is stored in the Run-Time data storage repository for:

    • (1) CONFIGURATION PARAMETERS - These are configuration parameters that are used by xNFs during installation & commissioning. Configuration parameters are typically used before the xNF has been brought up or is operational. For example, a 5G Network configuration parameter for a PNFs that sets the mechanical tilt which is a configuration setting upon installation.

    • (2) OPERATIONAL PARAMETERS - These are parameters that are derived, discovered, computed that are used by xNFs during run time AFTER the xNF becomes operational i.e. AFTER it has "booted up", been installed, configure. For example, in 5G Network, 5G PNFs may need to adjust a tower electrical antenna tilt. These operational parameters are Exo-inventory information, meaning it is information that doesn't belong in A&AI. In principle, some parameters might be both configuration and operational parameters depending on how they are used.

    • (3) POLICY INFORMATION - This type of information stores policy information that micro-services might need.
    • (4) APPLICATION INFORMATION - Information related to operational parameter.
  • DATA LAKE - Architecturally, the Configuration Persistence Service is designed to be a common services data layer which can serve as a data lake to other run time entities (ONAP components or external tools).
  • C&PS FUNCTIONS - The Configuration Persistence Service enables functionality to be performed by other entities. It will ENABLE the capability of another components or external tools within/or external to ONAP to perform the functions.
    • Configuration Management FUNCTIONS - Enables OSS configuration, optimization, and LCM operations.
    • SYNCING - The Configuration Persistence Service enables the ability to sync data between initial and delta changes ONAP & the xNFs.
    • DATA RECOVERY - It will allow for the recovery of data once a source of truth is defined.
    • UPDATES - It will allow for updates, delta changes, and incremental updates to be performed.
    • RESTORATION - It will allow for the recovery and restoration of data to a fall back point.
    • DATA HISTORY - It will allow an operator to see a history of changes in data. This will includes the versioning of the data, which is also associated with updates, roll back, restoration. Time series management is associated with data history management.
    • AUDITING - It will allow for auditing of configuration and parameters against a "golden" template. It itself stores & provides the data for another thing to perform the auditing. Consistency checks.
    • ROLL BACK - It will allow for rollback back to "save points" or recovery points.
    • ACCESS CONTROL - A security topic, which allows the definition of policies, of who and what they can update.
    • TOPOLOGY TRAVERSAL - It will enable the ability for something to traverse the relationship between data elements.
    • MODEL ADAPTION - Depending on the schemas used to define the DB data elements; it allows for the adaptation or transformation of models from other sources (e.g. ORAN or 3GPP models).
  • 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. The DB shall be designed to accommodate distributed operation as part of its role in the ONAP installation.


Image RemovedImage Added

The more detailed diagram:

Image RemovedImage Added


SCOPE

Functionality supported by a Configuration Persistence Service

...

  • SHARED SERVICE - The diagram below shows how the Configuration Persistence Service project fits into the overall ONAP architecture as a shared (common) service serving as a data layer for other ONAP components.

  • A&AI INDEPENDENCE - The Configuration Persistence Service stores information that is conceptual distinct from A&AI. The data is related because the DB also needs to keep track of the existence of xNFs; and A&AI is the master of resources & services. For more information about how information from A&AI is "synced" with the Configuration Persistence Service see the Operational Description section below.

  • DATA LAYER - Architecture conclusions is that this component should serve as a data layer to other components and be a data lake serving as a repository for storing run-time information. It shall also be within the shared services part of the architecture. Architecture concluded that this project should be an independent component in ONAP platform.

  • SCOPE (Type of Info Stored) - The type of information stored in the Configuration Persistence Service is run-time configuration, operational, and policy information.

  • ARCHITECTURE CONSISTENCY - The project is consistent with a data-centric ONAP architecture.

Image Removed

DEPLOYMENT VIEW


Image Added


Excerpt IncludeDW:CPS-78: Deployment ViewDW:CPS-78: Deployment ViewnopaneltrueThe following are links to Architecture related pages that describe the flows and component interfaces:

...

A dependency something that RunTime Config DB needs to operate properly.

Image RemovedImage Added

Direct Dependencies - RunTime Config DB depends directly on the following ONAP projects:

...

RESOURCES


•Primary Contact PersonsPerson:

...

The C&PS Roadmap from R6 to R8

Image AddedImage Removed

Continuing on ...

Image RemovedImage Added


The following is a table of the CPS release Pages:

...