Page History

...

• 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

The following are links to Architecture related pages that describe the flows and component interfaces:

...

BASIC CONCEPTS & PRINCIPLES

Image Added

• ASSOCIATIONS - These are "linkages" between elements within elements (or data records) in the database. Thus, this database is a relational database in the connective sense of a relational database (as opposed to the composition sense of a relational database).

• CARDINALITY RULES - This allows for the specification of a cardinality of element associations. For example, one PNF might have a limit to the number of associated logical elements, such as a Logical Cell that it is allowed to have.

• LINKING RESTRICTIONS - There may be rules which allow a operator to specify restrictions on the kind of associations that can be made. For example, an operator might want a particular kind of PNF to link to a specific kind of Logical object, such as a cell.

• DATA LAYER - This project is meant to serve as a data layer to other ONAP components. This means that it will be an intermediary for a component to write and access data.
• PERSISTENCY - The Configuration Persistence Service is meant to store data persistently, which means that it can hold data over time without losing it. 
• SYNCHRONIZATION - The concept of synchronization is the ability to align data between the database and something else, such as an external source, or a xNF. For example, the Configuration Persistence Service needs to synchronize to A&AI view of the available resources in the system. See the section on Synchronization below.
• STORAGE vs OWNERSHIP - The Database STORES data, provides persistency, and gives access to data. The information is created, defined and used by other ONAP components. The OWNERSHIP and life cycle management is the responsibility of that other ONAP component. The DB stores the data but does not own the data. The result is that other ONAP components can freely access that data without other components creating new APIs. Thus, components don't have to have own data rather the database serves as steward of the data. If the owner is the only persona that writes the data, there should be no race conditions of two entities trying to write or modify data.
• ACCESS CHARACTERISTICS - Historical data and current data do not necessarily share the same characteristics & requirements. There might be multiple data base technologies that underlie the operation of the service.

...

...