Overview

Scope

What is this release trying to address?

1. Upgradability (CPS, NCMP)
   1.  Version strategy to  control Continuous Delivery (CPS and NCMP)
      1. Technical debt of NCMP data be handled by Liquibase in CPS
   2. Yang Module Upgrade
      1. backward compatible
      2. backward incompatible
         1. Data Transformation/Migration
         2. Drop (and resync) 
2. Service Maturity CPS
   1. Delivery Pipelines 
   2. Helm best practices (design rules)
   3. FOSS audit
3. Service Maturity NCMP (TBC)
4. Performance (CPS, NCMP)
   1. CPS Data read 
   2. CPS Model-based query
   3. Registration algorithm change (using schemaSet hash)
5. CM Handle Connectivity State
6. Notification Configuration
   
   1. Model based
   2. Instance based
7. Query Propagation
   
   1. Amalgamate responses
   2. Capability Exchange (during registration/updates) 

Stretch Goals

1. Forwarding non-passtrough 
   
   1. data request
   2. notifications
2. Cache Configuration
   1. Model based
   2. Instance based, container, leaf
3. AAI integration
4. Extend Read(query) access to cached data (datastore ncmp-datastores:operational)
   1. cpsPath support in NCMP
   2. field' and 'depth' RestConf-Like support in CPS (and NCMP)
5. Extend CPS-Path (query) capabilities
6. CPS Target Based Access Control (TBAC)
   1. Ownership of dataspaces using OAuth2 
7. NCMP Access Control
8. Multiple Identifiers for Anchors (CM Handles)

Minimum Viable Product

N/A

Requirements

ONAP Best Practices (Global Requirements) and similar

CPS-temporal Requirements (TBC)

CPS-CORE / CPS-NCMP Requirements

Spin-off user stories, yet to be prioritized

Functionalities

User Stories

Longer term roadmap

• CPS-Core will have extended query capabilities based on XPath expression.
• CPS-Core will enforce and control ownership of data it holds
• NCMP will be to able to 'detect' and sync xNF in the network
  • Fine-cache cache control will determine what get cache for what xNF
• NCMP will support the query capabilities as CPS-Core and be extend with options similar to RESTConf's 'fields' and 'depth'

Release Deliverables

Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note, etc) of this release.

Sub-Components

• CPS-Core
  • cps-service
  • cps-rest
  • cps-ri (reference implementation)
• NCMP
  • cps-ncmp-service
  • cps-ncmp-rest
  • dmi-inventory
• Temporal DB
• DMI-Plugin
  • DMI Data Access
  • DMI Model Access

Architecture

High level architecture diagram

CPS is a new shared service in the ONAP Architecture:

Platform Maturity

See the centralized wiki page: London Release Platform Maturity

• API Incoming Dependencies

No Incoming API changes required

• API Outgoing Dependencies

API this project is delivering to other projects.

• Third Party Products Dependencies

Third Party Products mean products that are mandatory to provide services for your components. 

• Testing and Integration Plans

• CPS has high level of built jUnit test (>97 on all components) which is enforced by our maven build scripts
• CPS has built in Persistence Layer test ie. test that integrate with real DB instance covering all use cases and are part of  WoW
• CIST tests are part of CPS -Repo, see https://gerrit.onap.org/r/gitweb?p=cps.git;a=tree;f=csit;h=8505b66089f62b6431c1091edf820cbdbf4363d4;hb=HEAD
  And executed automatically through the cps-review-verification-maven-master CI Job
• E2E Integration with ONAP components was introduced in I-release and is now included in aforementioned CIST tests

• Gaps

No gaps Identified

• Known Defects and Issues

See dynamic Jira filter:

• Risks

Risk identified related to scope-creep, see London Risk Table 

• Resources

• Release Milestone

The milestones are defined at the Release Planning and all the supporting project agreed to comply with these dates.

• Team Internal Milestone

This section is optional and may be used to document internal milestones within a project team or multiple project teams. For instance, in the case the team has made agreement with other team to deliver some artifacts on a certain date that are not in the release milestone, it is recommended to provide these agreements and dates in this section.

• Documentation, Training

See the following centralized wiki: London Documentation

Other Information

• Vendor Neutral

If this project is coming from an existing proprietary codebase, ensure that all proprietary trademarks, logos, product names, etc. have been removed. All ONAP deliverables must comply with this rule and be agnostic of any proprietary symbols.

• Free and Open Source Software

FOSS activities are critical to the delivery of the whole ONAP initiative. The information may not be fully available at Release Planning, however to avoid late refactoring, it is critical to accomplish this task as early as possible.
List all third party Free and Open Source Software used within the release and provide License type (BSD, MIT, Apache, GNU GPL,... ).
In the case non Apache License are found inform immediately the TSC and the Release Manager and document your reasoning on why you believe we can use a non Apache version 2 license.

Each project must edit its project table available at Project FOSS.

Charter Compliance

The project team comply with the ONAP Charter.