| Gliffy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Table of Contents |
|---|
References
Jira Legacy server System Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-1964
Proposed JIRAS
| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
...
|
Associated Studies
| Priority | JIRA | Confluence | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 1 |
| |||||||||
| 2 |
| |||||||||
| 3 |
|
Issues & Decisions
| Issue | Notes | Decision | ||
|---|---|---|---|---|
| 1 | CPS to deliver java-interface only | This affects our Wow in many aspects.
|
Csaba Kocsis proposed that CPS Team will deliver Java impl. first and then E// will take our code and wrap and a REST interface around it. Toine Siebelink CPS team will work out during |
Grooming how to demo withour REST interface, most like using Groovy (semi) Integartion Tests. Daniel Hanrahan his about to complete a test framework for test NCMP services. | ||||
| 2 | Validation in REST or Java Service | Balance between early validation and common code | Continue with current process. Review case by case Toine Siebelink Csaba Kocsis | |
| 3 | Why is NCMP forwarding the response, DMI could do this ? | Involve extra performance cost from CPS | Implementation needed because of TBAC | |
| 4 | Are Java doc expected to be published | Yes. Agreed to deliver as a separate artefact (Shall be versioned ... where should it go ?) | Versioning of the interface shall be the same as the service delivered by CPS. New v should not affect the interface, version numbers could change and shall be documented | |
| 5 | Delivery artefacts | Required Artefacts
AP to confirm with Andreas in team Lightening | Csaba Kocsis to revert | |
| 6 | Characteristics | Need to discuss priority of this. Delivering a functioning MVP for EPIC is important. Discussion and agreement with Peter T needed Still needed, might not get response because the new team are yet to start any integration. AP Kolawole Adebisi-Adeolokun to get a decision from Peter/David | Csaba Kocsis to revert | |
| 7 | Results - Why can't DMI send result after completion of job with be told to do so | Simply less work if DMI can decide itself, no additional interface in other components needed to trigger this.... | tbc with Kieran Mccarthy A / Rafael Rocha | |
| 8 | Exact form of Alternate ID(s) FDNs | uri-FDN and LDNs should contain "/" and not "," as delimiters at the start of the naming attribute FDN example :
URI FDN example :
Should be compliant with 3GPP, should start with '/ ' https://github.com/jdegre/5GC_APIs/blob/Rel-18/TS28532_ProvMnS.yaml | Kieran Mccarthy A Users are advised to use URI-FDNs for alternate IDs to minimize performance impacts of conversions etc. Rafael Rocha ALL cps | |
| 9 | MVP (Minimum Viable Product) for DCM |
|
| |
| 10 | DataJob Read v Write prioritization | Write should be prioritized over read | ||
| 11 | Use of '/ ' causes some issues | Not at issue. FDN can support / and , | ||
| 12 | Prioritize CPS-2009 Update remaining existing/legacy NCMP APIs to support alternate Id (FDN) - Developer Wiki - Confluence (onap.org) - over Read. | New Epic requested for DataJob Read sperate this from 1964. Expected even earlier than q3 Agreed to move higher on R14 - #17 | ||
| 13 | NCMP still need to convert Legacy Event to Cloud Event before we can Update the Legacy APIs to support AlternateId | Re-prioritise [CPS-1704] Separation of Headers from Event Payload for Legacy Events - ONAP JIRA over CPS-2009 Update remaining existing/legacy NCMP APIs to support alternate Id (FDN). Kolawole Adebisi-Adeolokun to get agreement with stakeholders | Currently ETH are only consuming the LCM event and we agreed shall remain Legacy event for MVP delivery. | |
| 14 | Decision to add status & result as part of this MVP | No new epic required for write, maintain current priority, wrap up this epic with;
| ||
| 15 | Is the requestId in the southbound request equal to the dataJobId coming in from the northound interfaces? (see writeJob for example) | Can the dataJobId used as the requestId? | Kolawole Adebisi-Adeolokun confirmed dataJobId can be used as the requestId | |
| 16 | Define & agree on a Java interface (do we need a different method for write) The output should be defined | We need a clarification on the response. | Kolawole Adebisi-Adeolokun // The output is currently being define by team Lighting AP @ko to follow-up |
Requirements
E2E Requirement (for context)
Requirement | Additional Information | |
|---|---|---|
| 1 | rApps shall be able to send async data requests and get back a job Id to track the execution/status of the job and at the end get the results of the job in a specified datastore. | Implement new NCMP CRUDAQ data job / async interface aligned with 3GPP API - part of req #1 A client automation application shall be able to send async request to read, query and write network configuration. Current NCMP capabilities shall be extended to also support RANOAM CM data jobs.
|
Functional
Interface | Requirement | Additional Information | Sign-off | |
|---|---|---|---|---|
| 1 | CPS-I-01 | NCMP to provide support for Data jobs qualifier during registration. |
| Updated -> qualifier changes during II only Csaba Kocsis |
| 2 | CPS-E-11 | NCMP to provide Java interface that can support Data jobs request
|
| Kieran Mccarthy A Csaba Kocsis All cps |
| 3 | CPS-E-12 (TBC) | NCMP shall provide Java interface which are expected to return EMS/DMIs Job and Sub Job Status
|
| Csaba Kocsis all CPS CC Kieran Mccarthy A |
| 4 | CPS-E-11e |
|
| All CPS, Kieran Mccarthy A Csaba Kocsis |
| 5 | CPS-E-11 | NCMP is to be able to find the correct CM Handles based on the 'best' match for partial matches of the target FDN. The best match could be a Subnetwork (which are registered as separate cm handles) | Find best match, see solution proposal for details
| Csaba Kocsis All CPS |
Error Handling (new error scenarios)
Functional Requirement | Error Scenario | Expected Behavior | Sign-off | |
|---|---|---|---|---|
| 1 | #2 | Non Responding DMI during new DataJob Request | NCM shall send asynchronous message containing:
Client is responsible for retry. Wait for implantation proposal | Csaba Kocsis , CPS |
| 2 | #2 | Unmatched Alternate IDs | Toine Siebelink : Not discussed yet but I would suggest similar behavior as legacy bulk interface (async response with failed FDNS) - If an unmatched alternated (1 or more), send a response back to client saying no jobs or 0 subjob If request contains none-exited alternateid ? - Goes to client | Csaba Kocsis, all cps |
| 3 | #3 | Non Responding DMI during new status update | Error handling just by HTTP timeout (java interface will throw an exception) | Csaba Kocsis all cps |
| 4 | #4 | Not existing Topics | NCMP is NOT responsible for checking or handling messages to non existing (client) topics Also 'internal' topics are assumed to be set up correctly | Csaba Kocsis all cps |
| 5 | Misc. | Other Robustness
|
| Agreed to revisit robustness once basic happy and standard error scenarios (DMI not responding) have been implemented |
AP Kolawole Adebisi-Adeolokun To follow-up and check the possibility of merging this with the read & write or just keeping the error sci. separate as is;
High Level Solution
| Gliffy | ||||||
|---|---|---|---|---|---|---|
|
The 8 Steps
- DCM REST endpoint forwards request to NCMP for processing
- When processed subjobs are sent to relevent DMI
- DMI responds with acknowledgement of datajob received to NCMP
- NCMP informs DCM
- Job status sent to internal topic
- Topic published on Kafka channel
- Clients subscribed get status
- rApps receive status
Considerations
- Java interface to process a data job request
- Splitting the main job into multiple DMI sub-jobs
- Synchronous response with sub jobid
- Async mechanism to return list of jobs
- DMI or ENM responses ( Not CPS responsibility )
- Listen to the responses on internal topics
- Forward responses to the relevant topics
- Error Handling
- Specify the REST interface spec between NCMP and DMI plugin
Suggested User Story Breakdown
- Define DMI REST APIs and implement
- Handle request break-down (steps 1 and 2 on the diagram)
- Handle synchronous data-job response (step 4) and synch sub-job responses (steps 3)
- Agree on asynch data-job response with nm-engineering team
- Response schema for DMI response (Parallel to above steps 1, 2 and 3)
- Forward response (Parallel to above steps 1, 2 and 3)
- Delivery of product
- Error handling and more...
Solution Proposal
Sequence Diagram
Solution Aspects
- Deliver Java API only
- 3GPP (alternate Ids) only
- Asynchronous Impl.
- Job Id(s) One for each batch
- Qualifier (EMS Name, batch per Qualifier and/or DMI plugin)
- Update DMI
- DMI STub updates (already in CPS)
- publish job result to Kafka
Overlapping alternate Id (Sub-Networks)
Registered CM Handles & Alternate IDs
|
A) Batch JOb Job Request FOR below FDN:
/SubNetwork=Europe/ManagedElement=AB/GNBDUFunction=1
Should match from the start CM HANDLE 5 (longest possible common string)
...
C) Batch JOb Request FOR below FDN:
/SubNetwork=Europe/SubNetwork=Hungary
Should match CM HANDLE 2
Out-of-Scope
- Conflict management, DATAJOBS are BATCH OPERATION.
PO Comment
-CPS will need to leave epic open, Kolawole Adebisi-Adeolokun to organise a sync with team Lightning on their current progress
-dev wise, CPS has fulfilled all functional aspect of this epic but can't progress in further because the interface isn't ready yet from Team Lightning
-Should CPS consider demo ? - Kolawole Adebisi-Adeolokun to Check with team Lightning when we can arrange a demo upon a working interface