...
Agreed Epics (study proposals)
- CPS-1963 - Register alternate identifier (alternative for CM Handle ID)
- CPS-2007 - Update NCMP Events to include Alternate ID
- CPS-1964 - Support for Async datajobs Write
- CPS-2008 - Update existing single sync cmhandle APIs to support alternative id (containing FDNs)
- CPS-1992 - : NCMP to Support new 3GPP sync single FDN request
- CPS-2009 - Update remaining existing/legacy NCMP APIs to support alternateId alternate Id (FDN)
- CPS-2010 - NCMP to support datajob results in S3
Assumptions
| Assumption | Notes | ||
|---|---|---|---|
| 1 | All read and write use cases are Pass-trough i.e. no CM Data cached in CPS-NCMP | ||
| 2 | Alternate ID must be done first | This requirement relies on the completion of | |
| 3 | Datajobs are a new interface and we will be 3gpp compliant | Jobs are also referred to as datajobs | |
| 4 | DCM should be co-deployed with NCMP DCM shall be tightly coupled with NCMP (shall use Jar interface in building file) |
...
- Section 1.2.2. Page 6, suggestion: alphabetic order - Taken
- Section 1.3 Page 7 'dnPrefix starts with Subnetwork=XYZ'. I now see there is a command in the text. Maybe display "Submnetwork=XYZ,"this implies a partial match and that a node in Subnetwork XYZ-A would also fulfil the criteria. I don't think that is the intention and also that could be technically much more expensive (especially performance cost!). Can you clarify it is not a partial match maybe be include a delimiter in the FDN. the second point is that a subnetwork that is contained in another subnetwork coudl also match . I am not sure if that is the intention i.e. Subnetwork=AplhabethCity,SubNetwork=XYZ although technically this could perform OK again I think it is NOT the intention - Taken, scope of this should be agreed to be subnetwork=XYZ, (",")
- Section 1.3 Page 7 'Limited query' what is this referring to? Separate interface?! Sycn v. Async, not very clear - Taken, there's a separate interface. Limited query is for the single FDN. The idea is for query not to take too long
- Section 1.3 Page 8 'target ENMS' Please explain, client are NOT aware of ENMS instances so what is the target here instead?! - Taken, customers are not aware of the targeted ENM
- Section 1.3 General A picture illustrating existing/new interfaces would be very useful!
Similar to https://wikilf-onap.onapatlassian.orgnet/wiki/display/DW/ARC+Configuration+Persistence+Service+%28CPS%29+Component+Description+-+Montreal-R13#ARCConfigurationPersistenceService(CPS) -
ComponentDescriptionMontrealR13-6.SystemDeploymentArchitecture (see also overall comment) - Taken and agreed, proposed separate interface rather than an extension of interface 5. We'll have new interfaces - Section 3.2.1 Page 20. Exception #4 "> 30,000 records" what is a 'record' what is the expected behaviour, maybe best effort still or should NCMP decide to reject response (forwarding) when it becomes too large... CPS Core as the concept of 'fragments' (like a single MO) but NCMP isn't aware of this! A better definition would be a certain response size in Megabytes... But still when and how to decide or is it just a guideline/limit to be mentioned in documentation?! (same comment applies to a few use cases) - Taken, NCMP is not aware of any 'record', only yangmodules. ENM is saying they would like Rapps to not use the sync interface. Preventing them is more costly to implement. Advising them is better and less costly to implement by documenting it. It's easier to do for the read, but becomes more complicated, costly and problematic to do for write, delete. Check with Kieran - CPS haven't costed this yet. This are DB errors, not a decision NCMP should make. NCMP doesn't control this and it's now agreed to remove the limit of 30k 'as reported by underlying EMS. Agreed, taken
- Section 3.3.5. Page 42. Timer. What is the expectation if job cannot finish on time? Cancel ongoing request somehow, Rollback for writes ?!?!? - Taken, this is not in scope for Phase 1.
- Section 3.2.1 Page 21. you give a good definition of query on this page but it is not clear for me what is the ambitions-level. This is why I often argue for a separate epic for the 'Q' in CRUDAQ... Not knowing this make it very hard for us to estimate the cost of new interfaces include a 'Q' option! My advise is 'Evolve' start simple (MVP) and wait on customer feedback to see what they actually need instead of letting a bunch of (Ericsson) engineers dream up query capabilities. Engineers are very good at dreaming but it will quickly become very costly and you might end up having noting useful by the time you want to go to market! - Taken querying is just to 1 subnetwork MAX. These are passthrough parameters and shall be implemented in the URL these shall be directed to ENM. All the perimeters are all 3GGP compliant, NCMP just redirect these queries
- Section 3.2.3 Page 23. No Ste of NCMP to be able to report job status, is that correct? - Taken - Yes
- Section 3.6.4. Page 51. Alternative B. I am confused about the REST layer will DCM create a new REST layer and use NCMP as a service (libraries only). This will make a difference in who develops what and significantly impacts my cost estimates! Also the URL itself with start with ...\NCMP\vx\.... when the existing NCMP rest interface is used/expanded.... - Taken, Rest Interface - Lib are suppose to use the Java interface. DCM should expose API for data job, but not the same for the Sync job. If NCMP delivery lib, who is responsible for the rest interfaces ? This issue needs to be revisited as it's affect a whole amount of work Rafael Rocha to discuss with other archi and revisit. This is critical part of the study as it's impact NCMP delivery
...