...
- Proposed name for the project:
ConfigPersistencySvc
- Proposed name for the repository:
ConfigPersistencySvc
- Project Logo:
...
PROJECT DESCRIPTION
The Configuration Persistence Service is a platform component that is designed to serve as a data repository for Run time data that needs to be persistent. It is characterized by the following purpose statements:
...
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).
- Configuration Management FUNCTIONS - Enables OSS configuration, optimization, and LCM operations.
- 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.
The more detailed diagram:
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.
DEPLOYMENT VIEW
...
Architecture Info | Wiki Links |
ARCHITECTURE FLOWS | ARCHCOM: InfoFlow - RunTime Config DB Information Flow |
COMPONENT DESCRIPTION R6 | ARC RunTime DB Component Description - R6 Frankfurt |
COMPONENT DESCRIPTION R7 | ARC Configuration & Persistency Service (CnPS) Component Description - Guilin (R7) Release |
PROJECT PROPOSAL | RunTime Config DB Project Proposal (Oct 25 2019) |
- Guilin (R7) Release | |
PROJECT PROPOSAL | RunTime Config DB Project Proposal (Oct 25 2019) |
ARCHITECTURE CPS FLOW
The following page contains the CPS flows.
The flows detail the information flows in particular uses of CPS.
ARCHCOM: InfoFlow - Configuration Persistence Service (CPS) Information Flow
DEPLOYMENT VIEW
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
CPS SECURITY REQUIREMENTS
HTTPS
- CPS is compatible and in the process of migrating to a service mesh via the ONAP service mesh implementation. (https://gerrit.onap.org/r/c/oom/+/124287)
Logging and Monitoring
- CPS uses spring boots Logback and Log4j for logging information without exposing credentials (usernames and passwords).
- CPS has no logging of sensitive information such as usernames and passwords in plain text. The log files are only accessible within the authorized users of the application deployment.
SECURITY ASSURANCE
Input Validation
- CPS uses spring boot input validation support for initial input validation.
- CPS uses java mechanisms to further validate inputs such as parameters.
- CPS accepts models and data which are validated via a third-party tool (OpenDayLight YANG parser).
Authentication and Authorization
- CPS uses Basic Authentication control provided by spring security
- Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
- For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
When CPS is run with docker, the services use usernames and passwords that are stored as environment variables.
CPS does not run docker containers or services as 'root'.
- For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.
OPERATIONAL DESCRIPTION
C&PS DB operation is described. The following sections describe the basic operations of C&PS DB.
BASIC CONCEPTS & PRINCIPLES
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.
...
A dependency something that RunTime Config DB needs to operate properly.
Direct Dependencies - RunTime Config DB depends directly on the following ONAP projects:
...
RESOURCES
•Primary Contact PersonsPerson:
...
NAME | GERRIT ID | COMPANY | TIME ZONE | |
Benjamin Cheung | Benjamin Cheung | Nokia | ben.cheung@nokia.com | UTC-4 |
N. K. Shankar | N.K. Shankaranarayanan | AT&T | shankar@research.att.com | UTC-4 |
Marcin Krasowski | Marcin Sebastian Krasowski | Samsung | m.krasowski@samsung.com | UTC+2 |
Pawel Slowikowski | Samsung | p.slowikows2@samsung.com | UTC+2 | |
Krystian Kedron | user-7f92d | Samsung | k.kedron@partner.samsung.com | UTC+2 |
Carlos Manzanares | Carlos Manzanares | Nokia | Carlos.Manzanares@nokia.com | UTC+3 |
Fred Feisullin | Fred Feisullin | Verizon Wireless | Fred.Feisullin@Verizon.com | UTC-4 |
Sandeep Shah | Sandeep Shah | IBM | Sandeep.Shah@ibm.com | |
Philippe Leger | Philippe Leger | Bell Canada | Philippe.Leger1@bell.ca | UTC-4 |
Joachim Blixt | Samsung | j.blixt@partner.samsung.com | UTC+2 | |
Tony Finnerty | Ericsson | tony.finnerty@ericsson.com | UTC+1 | |
Theodore Johnson | theodore johnson | AT&T | johnsont@research.att.com | UTC-4 |
Niamh Core | Niamh Core | Ericsson | niamh.core@est.tech | UTC+1 |
Aditya Puthuparambil | Bell Canada | aditya.puthuparambil@bell.ca | UTC+1 | |
Claudio D. Gasparini | Pantheon.tech | claudio.gasparini@pantheon.tech | UTC+1 | |
Ruslan Kashapov | Pantheon.tech | ruslan.kashapov@pantheon.tech | EET (UTC+2) | |
Martin Vezeau | Martin Vezeau | Bell Canada | martin.vezeau@bell.ca | UTC-4 |
Other Contact People:
- Zu Qiang (Ericsson)
- David Kinsey
- KINGSLY LAWRENCE
- Swaminathan Seetharaman
- N.K. Shankaranarayanan
- Melanie Sater
- Anita Hai
- Marge Hillis
- Marc-Alexandre Choquette
- Michela Bevilacqua
- Mike Elliott
- Munir Ahmad
- Junfeng Wang
- user-4e793
- Fred Feisullin
- Claudio David Gasparini
...
The C&PS Roadmap from R6 to R8
Continuing on ...
The following is a table of the CPS release Pages:
...
Next Step | Description | Response |
---|---|---|
1 | 1A. Name of the project is appropriate (no trademark issues etc.); 1B. Proposed repository name is all lower-case without any special characters | Official Name of the project will be CONFIGURATION PERSISTENCE SERVICE Apache Geode is also using CPS, but it is not trademarked. Geode CPS |
2 | Project contact name, company and email are defined and documented | Toine Siebelink is the PTL and info can be found at 71834220 KEYPROJECTFACTS |
3 | Description of the project goal and its purpose are defined | The goal and purpose are on the project proposal: 71834220 PROJECTDESCRIPTION |
4 | Scope and project plan are well defined | The scope is defined in the project proposal: 71834220 SCOPE |
5 | Resources committed and available (company commitments, all people) | These can be found here: 71834220 RESOURCES Repo TBD |
6 | Contributors identified (people who add code) +2 | |
7 | Initial list of committer identified (elected/proposed by initial contributors) +1 | |
8 | Meets ONAP TSC Policies (NFR, GR, Code review, Testing, Audits, Documenting Interface) | The C&PS team intends to follow all ONAP TSC Policies. |
9 | Proposal has been socialized with potentially interested or affected projects (e.g. AAI, CDS, SO) and/or parties | TSC - TSC 2020-10-01 Requirement S/C - ONAP R8 Modeling High Level Requirements Architecture S/C - Modeling S/C - ONAP R7 Resource IM Call 2020-9-21 E2E Network Slicing (Requirements/Use Cases) SON PCI (Requirement/Use Cases) |
10 | Cross Project Dependencies (XPDs). In the case where a project will require changes in other projects, those projects are listed in the proposal, and a sponsoring developer in the project has been identified | There are no changes required upon other ONAP Platform component projects. |
11 | Tools have been identified and discussed with relevant partners (Linux Foundation, IT). Once the project pass the review:
| 1. Tool Chain: (action) 2. Tools: (action) 3. Code Review: using Gerrit for Code Review. 4. Testing: unit, integration test will be part of the developer work; ONAP goal for 55% testing code coverage. Will be using SonarQube. 5. Project Page: Configuration & Persistency Service R7 Developer page: Configuration & Persistency Service PoC |
...