| Table of Contents |
|---|
Requirements
| Priority legend | |||||
| Preliminary | Planned for current ONAP Release | In Progress | Paused/Blocked | Completed | De-scoped |
ONAP Best Practices (Global Requirements) and similar
| ONAP Requirement | Notes | CPS- Jira(s) | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
| ONAP script might help us with common quality issues and save reviewing time |
|
CPS-CORE / CPS-NCMP Requirements
| Priority | Epic/Component/Owner/Team/Target | Description | Notes | Jira(s) | |||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
CPS-Core Community & Ericsson Team 2 | Data Write/Read Performance | See also CPS-Core Read & Write (large load) Test Results from Wipro/Fujitsu See Montreal Read/Write Performance for latest performance results (23/08) |
| |||||||||||||||||||||||||||
| 2 |
CPS-NMCP Ericsson Team 1 | CM Handle Connectivity Freshness/Staleness | Need to model what staleness is (current CPS only has concept of model-sync state, nothing about connectivity) |
| |||||||||||||||||||||||||||
| 3 |
CPS-NCMP Ericsson Team 1 Mid Q4 Target | Update YANG schema-set for CM handle using ModuleSetTag | Update YANG schema-set for CM handle without removing and adding it Cached data is not in scope. Need to specify orphan handling of YANG modules (already built in ?) Introduce concept of ModuleSetTag to prevent unnecessary trips to nodes to get al Modules will require NCMP module loader (for upgrade of Inventory model) instead of Liquibase steps! |
| |||||||||||||||||||||||||||
| 4 |
CPS-NCMP Ericsson Team 2 | Merge CM data subscriptions in NCMP when forwarding it to DMI | Implementing Data Notifications & Subscription Notifications on a US by US basis Scope add: What kind of access controls are required on topics? Spike is required for this. Work Item created (23/05). |
| |||||||||||||||||||||||||||
| 5 |
CPS-NCMP Ericsson Team 2 | Access Control for resources to ensure that operators can restrict access control to only those users (human/machines) that are authorized to execute CRUD operations on those resources. |
| ||||||||||||||||||||||||||||
| 6 |
CPS-NCMP TBD TBD | CM data subscriptions from application to DMI [Part 2]. It includes creating subscription with wildcard cmhandles. | This epic was created to take on additional scope which got added to |
| |||||||||||||||||||||||||||
| 7 | TBC CPS-NMCP TBC TBC | Event Digest | Additional field to help clients filter CM AVC Events (S) | ||||||||||||||||||||||||||||
| 8 | TBC CPS-NMCP TBC TBC | AVC Subscription, advance filter | Filter on 'Type' instead of list of CM Handle IDs → 'Type' could be defined as the yang module set containing a specific module (name and version) (S) | ||||||||||||||||||||||||||||
| 9 |
CPS-CORE (& NCMP TBC) Deutsche Telekom | Support for list as top level data node |
| ||||||||||||||||||||||||||||
| 10 |
CPS-CORE (& NCMP TBC) Deutsche Telekom | CPS & NCMP Feature Enhancement for M Release |
| ||||||||||||||||||||||||||||
| 11 |
TBC TBC | Yet to agree priority | A decision was made to abandon json+problem format |
| |||||||||||||||||||||||||||
| 12 |
CPS-CORE & NCMP TBC TBC | Spike for documenting Kafka interfaces using AsyncAPI | - Documentation Generation - Code Generation (contract first, stubs) | ||||||||||||||||||||||||||||
| 13 |
CPS-NMCP TBC TBC | Refactor legacy NCMP ASync Response Events to use Cloud Events format | (M) |
| |||||||||||||||||||||||||||
| 14 | TBC | Support NCMP-CPS upgrade | Currently only custom upgrade is supported. (upon request) Requirement: It shall be possible to upgrade NCMP-CPS from release N-1 to N (without requiring manual intervention/workarounds). N is defined as any release requested by ESH Note. Need to agree version strategy: use current ONAP x.y.z. numbering. Ericsson to communicate when a version is to be 'delivered' and 'y' increased Technical Debt to be addressed: Liquibase is used in CPS to manage data(upgrades) in CPS Study: Resolve technical debt (mixed data). NCMP Data upgrade. CPS Core need to support model upgrade so that NCMP can use it, |
| |||||||||||||||||||||||||||
| 15 | TBC | Support multiple identifiers (alternatives for CM Handle ID) | (M) - Not sure. Scope not known yet. | ||||||||||||||||||||||||||||
| 16 | Access control for topics which are created by NCMP . | Spike needs to be conducted. | |||||||||||||||||||||||||||||
| 17 | Invoke YANG modelled action | Always on operational datastore. Supported for nmcp:passthrough-operational and if executed against ncmp:operational then it is always forwarded to dmi plugin. Is there another story for forwarding to be included as a dependency? Always run as async request. Is this dependent on CPS-1127 - see spin-off user stories table below this on. KMC : Can we deprioritize - this can be run against passthrough-operational for now. Just have to agree on the API / URL for the action to progress at this stage so that the passthrough-operational form is aligned with final operational form. | |||||||||||||||||||||||||||||
| 18 | Enhanced query support (fields) | Currently the passthrough has an 'fields' parameter to do a scoped query. Propose to support this in non-passthrough so it is promoted to a fully supported option, e.g. {ncmp-root}/ncmp/v1/ch/335ff/data/ds/ncmp-datastore:passthrough-operational? KMC : Do we support restconf like queries or xpath only? (L) . | |||||||||||||||||||||||||||||
| 19 | Enhanced query support (scope) | Currently the passthrough has an 'fields' parameter to do a scoped query. KMC : Do we support restconf like queries or xpath only? (L) | |||||||||||||||||||||||||||||
| 20 | TBC | Support ncmp-datastores:running for reading data (single CM handle, synchronous only) | See CPS-391 page for details about supported operations and combinations. Note: There can be some overlap between work items for #5, #6, #11 and #12. Read from operations. (S) - Forward only. No validation or data enhancements (add prefixis) | ||||||||||||||||||||||||||||
| 21 | TBC | Support ncmp-datastores:running for writing data (single CM handle, synchronous only) | (S) As per #18 | ||||||||||||||||||||||||||||
| 22 | TBC | Support relationships for 'Instance Identifier' | Should be possible to identify a cmhandle using multiple instance identifiers. (M) - Not sure. Scope not known yet. |
| |||||||||||||||||||||||||||
| 23 | Retrieve single module resource | /v1/ch/{cm-handle}/modules/definitions/{moduleName} (S) | |||||||||||||||||||||||||||||
| 24 | Access control for public interfaces (NCMP, CPS-Core, DMI?) | KMC : What level of access control is there today - both on CPS and NCMP interfaces? | |||||||||||||||||||||||||||||
| 25 | Fine-grained cache configuration | ||||||||||||||||||||||||||||||
| 26 | Support for HTTPS and authentication Use Service-Mesh? Both ONAP and Ericsson (applied ISTIO using Envoy Proxy side-car) are working towards this. Check with Gareth Roper | Validation required whether this is still needed. |
| ||||||||||||||||||||||||||||
| 27 | TBC | Send notifications on write operation in ncmp-datastores:running for (single CM handle, synchronous only) | |||||||||||||||||||||||||||||
| 28 | schema-set update for CM handle with cached data present | Need to address case with incompatible model changes. Scope: Upgrade of model that is cached? Lee Anjella to confirm. | |||||||||||||||||||||||||||||
| 29 | Invoke YANG modelled RPC | Specification required. Rebbot/Reset type of actions on node. | |||||||||||||||||||||||||||||
| 30 |
| DMI Audit for DMI restarts |
| ||||||||||||||||||||||||||||
| 31 |
| Fetch a list of cmhandles along with their private properties as response from NCMP. |
Spin-off user stories, yet to be prioritized
| Jira | Component(s) | Related Work Item | Description | Notes | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| CPS-NCMP | |||||||||||||||
| CPS-NCMP | |||||||||||||||
| CPS-NCMP | |||||||||||||||
| CPS-NCMP | |||||||||||||||
| CPS | Now handled by Fujitsu/Wpri (Work Item ?) ? | ||||||||||||||
| CPS |
Functionalities
User Stories
| Expand | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Type your task here, using "@" to assign to a user and "//" to select a due date
| Expand | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Type your task here, using "@" to assign to a user and "//" to select a due date
| Expand | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||
|
Other Information
Platform Maturity
See the centralized wiki page: London Release Platform Maturity
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.
...