Table of Contents | ||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Paris (P)
Louvre Museum (Credit Wikipedia)
Requirements
legend
Preliminary | Priority Agreed | In Progress | Pending Integration | Paused/Blocked | Completed | De-scoped |
CPS-CORE / CPS-NCMP Requirements
Epic/Component/Owner/Team/Target | Description | Notes | Jira(s) | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 |
| CPS-Core Feature Enhancement for Oslo Release: Delta Feature | NOTE: Reopened |
| ||||||||||||||||||||||||||||||||||||||||||||||
2 |
| NCMP shall support retaining the order of CM Change Notifications |
| |||||||||||||||||||||||||||||||||||||||||||||||
3 |
| Request to update Event Schemas |
| |||||||||||||||||||||||||||||||||||||||||||||||
4 |
| New Generic interface to handle policy interface |
|
| ||||||||||||||||||||||||||||||||||||||||||||||
5 |
| Support for Async datajobs Not just for reading specific fdn, but rather QUERY Group of FDN , it's just a broadcast to every DMI plugin. The response should mimic sending a broadcast to 2 or more CM Handles CPS Team will only do java interface. REST Interface is done in DCM | NEW interface aligning with 3GPP i.e FDN instead of CM-HandleIds (Read use case can re-use existing dataOperationz impl. after mapping FDNs to CMHandleIds for input and back for output!) Read, Create, Update, Delete and Action support. I.e for passthrough only
Add as part of this epic
No new epic for write req. |
| ||||||||||||||||||||||||||||||||||||||||||||||
6 |
| Update remaining existing/legacy NCMP APIs to support alternateId (FDN) | Update existing/legacy NCMP APIs to support FDN / alternateId Depends on
Now includes
Agreed with stakeholders on These open issues are not a blocker, we would leave LCM event as Legacy event and proceed with
|
| ||||||||||||||||||||||||||||||||||||||||||||||
7 |
| CM-handle search that returns 200k Cells (50k CM Handles) |
| |||||||||||||||||||||||||||||||||||||||||||||||
8 |
| Async datajob Read to S3 (Minio impl) | NCMP to introduce a qualifier to be used along with the DMI plugin so NCMP can break the request with multiple cmhandle into batches based on the DMI plugin and the Qualifier (where qualifier should be EMS name / id).
| |||||||||||||||||||||||||||||||||||||||||||||||
9 |
| NCMP to support the 3GPP ProvMnS CRUD interfaces. NCMP to Support new 3GPP sync single FDN request | Implement new NCMP CRUDAQ sync interface aligned with 3GPP API (Read and write use cases) - Wrapper on existing/legacy API | |||||||||||||||||||||||||||||||||||||||||||||||
10 | Async datajob Read (Write output to Kafka) | TBC: Stakeholders needs to check validity of this requirement. | ||||||||||||||||||||||||||||||||||||||||||||||||
11 |
| Forwarding CM Data Notifications to Topic in Subscription |
Interdependent on -
Dropdown from #7 due to the whole CM Data Notification Subscription is estimated for Q2 25 by // therefore deprioritized |
| ||||||||||||||||||||||||||||||||||||||||||||||
12 |
| CM Subscription with DME interface |
Newly Added |
| ||||||||||||||||||||||||||||||||||||||||||||||
13 |
| TBAC - 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. | TBAC Study still ongoing, schedule an internal meeting to go through study doc, until sidecar is well define and implemented cps can't do nothing. Sidecar should specify the interfaces. |
| ||||||||||||||||||||||||||||||||||||||||||||||
14 |
| CM data subscriptions from application to DMI [Part 2]. For all cmhandle (general) | This epic was created to take on additional scope which got added to |
| ||||||||||||||||||||||||||||||||||||||||||||||
15 |
| AVC Subscription, advance filter. Part 2 of cmhandles It includes creating subscription with patternmatch cmhandles. | 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) | |||||||||||||||||||||||||||||||||||||||||||||||
16 |
| Event Digest | Additional field to help clients filter CM AVC Events | |||||||||||||||||||||||||||||||||||||||||||||||
17 | 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
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, Liquibase is used in CPS to manage data(upgrades) - Now available.
(XL) - Scope needs to be defined. Risk is scope not identified, efforts might increase. |
| ||||||||||||||||||||||||||||||||||||||||||||||
18 |
| Spike for documenting Kafka interfaces using AsyncAPI |
| |||||||||||||||||||||||||||||||||||||||||||||||
19 |
| Refactor legacy NCMP ASync Response Events to use Cloud Events format | (M) TBC |
| ||||||||||||||||||||||||||||||||||||||||||||||
20 | Access control for topics which are created by NCMP. | Spike needs to be conducted. Dependent of TBAC implementations. | ||||||||||||||||||||||||||||||||||||||||||||||||
21 | Invoke YANG modelled sync action | Invoke YANG modelled action Invoke YANG modelled RPC, Specification required. Rebbot/Reset type of actions on node. Include to the sync one | 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 sync 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. (S) - for passthrough. *Spec out before Sept'23. No implementation.
can datajob cover this ?, currently no support for 'actions'. Action name at the end of resourceid. split ticket into, action with and without responses. | |||||||||||||||||||||||||||||||||||||||||||||||
22 | 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) . *Spec out before Sept'23. No implementation. | ||||||||||||||||||||||||||||||||||||||||||||||||
23 | 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) *Spec out before Sept'23. No implementation. | ||||||||||||||||||||||||||||||||||||||||||||||||
24 | TBC | Support | 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) | |||||||||||||||||||||||||||||||||||||||||||||||
25 | TBC | Support | (S) As per #18 | |||||||||||||||||||||||||||||||||||||||||||||||
26 | TBC | Support relationships for 'Instance Identifier' | Should be possible to identify a cmhandle using multiple instance identifiers. |
| ||||||||||||||||||||||||||||||||||||||||||||||
27 | Fine-grained cache configuration | |||||||||||||||||||||||||||||||||||||||||||||||||
28 | Support for HTTPS and authentication
| Validation required whether this is still needed. |
| |||||||||||||||||||||||||||||||||||||||||||||||
29 | TBC | Send notifications on write operation in | ||||||||||||||||||||||||||||||||||||||||||||||||
30 | schema-set update for CM handle with cached data present | Need to address case with incompatible model changes. | ||||||||||||||||||||||||||||||||||||||||||||||||
31 | Invoke YANG modelled RPC | Specification required. Rebbot/Reset type of actions on node. | ||||||||||||||||||||||||||||||||||||||||||||||||
32 |
| DMI Audit for DMI restarts | After restart, trustlevel loses all data. TrustLevel is not currently in use now, however this becomes an issues after TrustLevel restart. The states goes to 'NONE' after TrustLevel restart TBC |
| ||||||||||||||||||||||||||||||||||||||||||||||
33 |
| Fetch a list of cmhandles along with their private properties as response from NCMP. |
Technical Debt
User Stories
Open User Stories for Paris Release
Jira Legacy | ||||||
---|---|---|---|---|---|---|
|
User Stories Closed in Paris Release
Other Information
Platform Maturity
See Best Practices Badging Status Dashboard by Tony Hansen
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.