DESCRIPTION: Configuration Persistence Service (CPS) is a data lake repository for configuration and operational parameters. Configuration Persistence Service is a common service component that ONAP components can access write and read information to. The term "config" is used in the name for legacy purposes, but the use case is not limited to just configuration parameters and it is intended to be a repository for Operational parameters, and eventually policy information.
WHEN EXECUTED: This information flow is used during Run Time, when configuration or operational data is written to the Configuration Persistence Service.
PURPOSE: Configuration Persistence Service serves as a data lake as a common service and data layer for ONAP components and micro-services.
INFORMATION PASSED: Configuration information (from CM Notify) or operational information (derived during ONAP operations).
ACTORS:
For more information and details you can visit the RunTime DB Use Case Wiki at: CONFIGURATION PERSISTENCE SERVICE R6
The: ARC RunTime DB Component Description - R6 Frankfurt
wiki describes a more detailed figure and description of the component.
PURPOSE OF RUNTIME CONFIG DB:
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. For example 5G Network run-time instance configuration information. and
(2) OPERATIONAL PARAMETERS used by ONAP and xNFs. Exo-inventory information is information that doesn't belong in A&AI.
ACCESS TO RUNTIME DB (READ/WRITE):
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.
SYNCING NEW xNF ADDED or DELETED (A&AI):
ELEMENT SYNC - Software keeps the A&AI elements with the elements in CPS in Sync. When the network first being established, a GetAllPNFs function from A&AI can be used on startup.
INDEXING:
The above diagram shows the usage of CPS
It shows the four basic flows captured in the diagram.
Information Flows to CPS or from CPS DB during Run Time Operation of ONAP.
1 INFORMATION FLOW DATA WRITTEN TO CPS:
Information Flows show data being written to the CPS
New Information is written to CPS from a Component or a Micro-service
The following three basic flows are described:
2 INFORMATION FLOW DATA READ FROM CPS:
Information Flow from CPS
Other components are reading from CPS.
Taking information from CPS and using it to send to xNF components
Race Conditions - a hysteresis (a time difference) between writing information (from a Kafka broker) and a read request arriving before the writing has finished.
ONAP is ready & running:
RunTime Config DB is setup (Design Time):
A data structure which is common for all different vendor xNFs will be used for the CPS.
Domain oriented components can be used where all of those components share common information.
Any micro-service or ONAP platform component can define information in the data structure.
Before Run Time, the CPS is setup with the appropriate data structures that it needs to work from SDC CSAR Service definition file package.
The Run Time Config is schema for the records CPS are defined in advance. In the future (later releases) the RunTime Config DB schema may defined data structures on the fly.
Topology-type can be represented through the xNF associations in the schema
DESIGN TIME - The schema of data structure of RECORDS the run Time Config DB can support are created and defined in advance.
RUN TIME - During Run Time the data and associations are DYNAMICALLY Run Time config DB updated using the schema of the records.
The CPS is a Data layer common service data lake.
There has been quite a bit of discussion related to how to architect the RunTime DB component.
In R6 is was determined, that it should be a common service as a data layer to other ONAP components.
These four flows show the usage of CPS
The following UML diagram shows the Information Flow for CPS
@startuml
participant PNF
participant VESCollector
participant DMaaP
participant CPS
autonumber
group RUNTIMEDB UPDATE
hnote over PNF : CM Notification
PNF -> VESCollector : CM Notification
end
group Run Time DB Writing
hnote over VESCollector : VES Event
VESCollector -> DMaaP : VES Event
DMaaP -> CPS : Subscription
hnote over CPS : Writes Information
RunTimeDB -> CPS : Write Information
end
@enduml |
1. VES Event – VES Event Received
A VES event (CM Notify) is received by the DCAE VES collector sent from the PNF.
A xNF determines that a configuration parameter needs to be updated, thus it triggers a CM Notify towards ONAP with the objective of updating the CPS.
2. Publish on DMaaP – VES Collector publishes the event onto DMaAP
VES Collector Publishes on DMaaP with the CMNotify Topic
3. Subscription on DMaaP – CPS gets the Notification
CPS subscribes to the Event.
In the initial release (R6), CPS will use SDN-C's DMaaP listener capability; but the goal is that RunTime Config DB is a separate independent component so it would have its own DMaaP Listener.
4. Updates DB – CPS is updated with the information
CPS is updated with the information
The following UML diagram shows the xNF Update flow from updates in A&AI for CPS
In this flow, A&AI has determined that a xNF (PNF or VNF) has been removed or added to the network.
And so downstream dependent components need to update their information that a xNF has been removed/added.
In the case of RunTime, there would be a record for that xNF and it would be need to be removed/added
the basic mechanism of how this is done is reused (nothing new is introduced): A&AI publishes an notify event on DMaaP bus,
and RunTime (component) subscribes to that event and updates itself.
@startuml
participant AAI
participant DMaaP
participant CPS
autonumber
group CPS UPDATE
hnote over AAI : xNF Update Notification
AAI -> AAI : Detects xNF Update
end
group CPS Writing
hnote over DMaaP : Notification
AAI -> DMaaP : AAI Update Notification
DMaaP -> CPS : Subscription
hnote over CPS : Updates xNF Update
RunTimeDB -> CPS : Updates xNF Information
end
@enduml |
The describes the xNF information updates and keys based on xNF update.
1. AAI Determines update – A xNF has been removed or added
AAI determines a xNF has been removed/added from the network. Thus, downstream ONAP components need to be aware of this change in the network.
2. AAI publishes on DMaaP – AAI publishes on DMaAP
AAI publishes on DMaaP A&AI Notify, that a xNF status has changed.
3. Subscription on DMaaP – DMaaP gets the Notification
RunTime Config DB subscribes to that event; and so, gets the AAI updates.
4. Updating the RunTime Config DB – CPS is updated.
REMOVAL - CPS removes the record for that xNF
ADDITION - If AAI determines that a new xNF is added to the network, then CPS needs to setup a new record for that xNF with the default data structure and configuration. Default Configuration is setup. For a new xNF a pre-defined schema record is used for that xNF.
The following UML diagram shows Where another ONAP component or Micro-Service updates CPS
@startuml
participant ONAPComponent
participant DMaaP
participant CPS
autonumber
group RUNTIMEDB UPDATE
hnote over ONAPComponent : Info Update Notification
ONAPComponent -> ONAPComponent : Determines xNF Update
end
group CPS Writing
hnote over ONAPComponent : Notification
ONAPComponent -> DMaaP : Update Notification
DMaaP -> CPS: Subscription
hnote over CPS: Updates xNF Update
RunTimeDB -> CPS : Updates xNF Information
end
@enduml |
The describes the xNF information updates and keys based on xNF update.
1. Micro Service Determines Update Needed – The mS determines an update is necessary.
The micro service, (policy), controller, ONAP component during operation determines an update is needed and action needs to be taken.
When this happens, it will publish onto the DMaaP Bus. Composes policy guidance. When that request comes in the controller, makes a config change on the underlying xNF device, with a successful outcome, it then determines that an update to the Runtime Config DB needs to be updated.
(Controller/Micro-Service/ONAP component) determines that an update is needed > Controller TO xNF > NetConf Yang > Update CPS
2. mS publishes on DMaaP – Publish onto DMaaP
The mS publishes an event on to the DMaaP Bus.
3. Subscription to DMaaP – Subscription from DMaaP
CPS Receives the event from the DMaaP Bus.
4. Updates DB – The Database is updated
CPS is database is updated with the information that is needed.
The following UML diagram shows Where a Controller (SDN-C, SDN-R) is updates the CPS because of a configuration parameter update.
During this flow a configuration update is also sent to the PNF or VNF.
This flow is used when a Controller determines that a Config change is needed. The Controller sends a message to the xNF (via Ansible, or NetConf). The Controller would then send an update on DMaaP which will then update CPS.
@startuml
participant Controller
participant DMaaP
participant CPS
participant xNF
autonumber
group CPS UPDATE
hnote over Controller : Config Update Notification
Controller -> Controller : xNF Config Update Needed
end
group Run Time DB Writing
hnote over Controller : DMaaP Notification
Controller -> DMaaP : Update Notification
DMaaP -> CPS : Subscription
hnote over CPS : Updates xNF Update
RunTimeDB -> CPS : Updates xNF Information
hnote over Controller: Send to xNF
Controller -> xNF : Sends config update to xNF
hnote over xNF: Updates Configuration
end
@enduml |
1. Controller Determines Configuration Update Needed – The Controller determines an update is necessary.
The controller determines a configuration (parameter) update is needed and action needs to be taken.
2. Controller publishes on DMaaP – Publish onto DMaaP
The Controller publishes an event on to the DMaaP Bus.
3. Subscription to DMaaP – Subscription from DMaaP
CPS Receives the event from the DMaaP Bus.
4. Updates DB – The Database is updated
CPS is database is updated with the updated configuration parameter that is needed.
5. Controller sends to xNF – The Controller sends to xNF
The controller of the xNF updates the xNF with the configuration information. The xNF updates its internal storage.
The following UML diagram shows reading information from the RunTime Config DB.
@startuml
participant CPS
participant DMaaP
participant ONAPComponent
autonumber
group Run Time DB Reading
hnote over CPS : Update Occurred
RunTimeConfigDB -> DMaaP : Publishes Notification
DMaaP -> ONAPComponent : Publishes Notification
hnote over ONAPComponent : Subscribes to Notification
ONAPComponent -> ONAPComponent : Updates Information
end
@enduml |
1. CPS has Update Needed – The Controller determines an update is necessary.
The RunTime Config DB determines a configuration (parameter) update is needed and action needs to be taken.
2. CPS publishes on DMaaP – Publish onto DMaaP
The RunTime Config DB publishes an event on to the DMaaP Bus.
3. Subscription to DMaaP – The interested ONAP component Subscribes to updates from CPS from DMaaP
The ONAP Component Receives the update event RunTime Config DB from the DMaaP Bus.
4. ONAP Component updates info – The ONAP Component is updated
The ONAP Component is database is updated with the updated configuration parameter that is needed.
The post-conditions for the DB:
Wiki Page for RunTime Db CONFIGURATION PERSISTENCE SERVICE R6
Architecture component Description ARC RunTime DB Component Description - R6 Frankfurt
| Files | File |
|---|---|