Need to model what staleness is (current CPS only has concept of model-sync state, nothing about connectivity) kieran mccarthy to spec this
Staleness will be modelled as a public property and notification will be sent/ notifiable. Assumption is that the solution will accommodate the same behavior's for all public properties.
Support Alternate ID (3GPP) for CM Handle ID Implement FDN base CMhandle, this should be done before patternmatch cmhandle can be implemented
NCMP's CmHandle registration endpoint shall be changed to accept a new String parameter which proposed name is alternateId. NCMP Inventory CPS-NCMP-I-01 should be able to support alternate id update
* NCMP LCM event should send notification events with FDN identifier in the alternateid (deprecation period: correlationid=md5-hash, alternateId=FDN) * NCMP LCM event should send notification events with FDN identifier in the correlationid (after deprecation period: correlationid=md5-hash (existing) or uri-FDN (new ones), alternateId=FDN)
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 wil 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 Note: Q(uery) is SUBNETWORK-wide read and should be done separately using a different endpoint for clarity and separation!
* 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). * NCMP shall create one or multiple EMS job ids depending on FDNs requested * NCMP shall provide an interface to get status of an EMS job id (forward request) * NCMP shall provide an interface to get results of an EMS job id * NCMP shall send the results to Kafka topic
Moved up on Not discussed for long time but need new attention so these problems don't continue while building DCM Alignment of CPS/NCMP build artifact versions with EIC
Moved up on Not discussed for long time but need new attention so these problems don't continue while building DCM Alignment of CPS/NCMP build artifact versions with EIC
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). * NCMP shall create one or multiple EMS job ids depending on FDNs requested * NCMP shall provide an interface to get status of an EMS job id (forward request) * NCMP shall provide an interface to get results of an EMS job id * NCMP shall send the results to S3
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.
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)
2425
TBC
CPS-NMCP
TBC
TBC
Event Digest
Additional field to help clients filter CM AVC Events (S)
2526
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,
Liquibase is used in CPS to manage data(upgrades) - Now available.
Still need to discuss the 'backward incompatible' → What interfaces should NOT be impacted Kieran mention NBI - northbound interfaces
Propose workshop, Spike needed from CPS
(XL) - Scope needs to be defined. Risk is scope not identified, efforts might increase.
Spike for documenting Kafka interfaces using AsyncAPI
- Documentation Generation - Interface Naming - Cloud Events specifics asyncapi-cloud-events- Roll out for legacy events
- Code Generation (contract first, stubs) Add label of techdebt Kolawole Adebisi-Adeolokun not an immediate req for
2728
Jira Legacy
server
System Jira
serverId
4733707d-2057-3a0f-ae5e-4fd8aff50176
key
CPS-1704
CPS-NMCP
TBC
TBC
Refactor legacy NCMP ASync Response Events to use Cloud Events format
(M) TBC
Jira Legacy
server
System Jira
columnIds
issuekey,summary,assignee,status
columns
key,summary,assignee,status
maximumIssues
20
jqlQuery
"Epic Link" = CPS-1704
serverId
4733707d-2057-3a0f-ae5e-4fd8aff50176
2829
Access control for topics which are created by NCMP.
Spike needs to be conducted. Dependent of TBAC implementations.
2930
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.
3031
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? resourceIdentifier=/&options=(fields=ericsson-enm-comtop:ManagedElement/ericsson-enm- gnbcucp:GNBCUCPFunction/EndpointResource/LocalSctpEndpoint/attributes(sctpEndpointRef),
KMC : Do we support restconf like queries or xpath only?
(L) .
*Spec out before Sept'23. No implementation.
3132
Enhanced query support (scope)
Currently the passthrough has an 'fields' parameter to do a scoped query. scope=ericsson-enm-comtop:ManagedElement/ericsson-enm-gnbcucp:GNBCUCPFunction/ EndpointResource/LocalSctpEndpoint/attributes(interfaceUsed==X2))
KMC : Do we support restconf like queries or xpath only?
(L)
*Spec out before Sept'23. No implementation.
3233
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)
3334
TBC
Support ncmp-datastores:running for writing data (single CM handle, synchronous only)
(S) As per #18
3435
TBC
Support relationships for 'Instance Identifier'
Should be possible to identify a cmhandle using multiple instance identifiers. (M) - Not sure. Scope not known yet.
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
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.
