References
Jira for this study: CPS-2020
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
- 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 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) |
Meetings
| Date | Attendees | Recording |
|---|---|---|
| N/A | |
| All CPS, Kieran Mccarthy A Rafael Rocha | |
| All CPS. Kieran Mccarthy A Rafael Rocha | Requirement gathering Support for Async datajobs
|
| All CPS. Csaba Kocsis Rafael Rocha | 3GPP Alignments CPS Workshop (02) Requirement gathering Support for Async datajobs - In person workshop
|
| All CPS. Csaba Kocsis Rafael Rocha |
2. Update existing single sync cmhandle APIs to support alternate id (containing FDNs)
Video Link: |
Study Comments
Overall Comments
- Please use existing interface names for CPS-NSMP where they are being mentioned. Propose new names where required.
I have now included the (new) interface names in this wiki: https://eteamspace.ericsson.net/display/RERIC/CPS-2020+DCM+%28Distributed+Configuration+Management%29+Overview+Study
Detailed Comments
- 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://wiki.onap.org/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
| 1 | Section 3.2.1 Page 20. Traceability. Which component(s) are responsible for tracing. This information could easily end up being duplicated/done in too many places and in future lead to bugs about 'excessive' logging! (same comment applies to all use cases) - | who's responsible for this ? not also mentioned in the list of steps. Rafael Rocha and Kieran to discuss and come back with suggestion because EST does not have hook to EIC/ENM login as of today still needs to be discussed with Kieran/Csaba/Rafael | Toine |
| 2 | Section 3.9. Define Application System Capabilities Page 57. REQ-DCM-001 Please define throughput with an average response size (in KB) | Taken, Size is not defined yet. Rafael Rocha to revisit. At least based on average size. Request latest doc. meeting with other stakeholders Rafael to update | Toine |
| 3 | Section 4.2.1.5 Page 61. Definition of Done. This definition is written as if a client has executed the required operation. Normally t DoD (for implementation teams) are written in the form of 'the system can register new device with and alternat id' Actual HOW the client populates them cannot be a definition of done. Its is more like an expectation...' I think the how the IDs should be populated in each phase should be documented in a separate diagram (I think you have that somewhere already). | Taken - Steps missing for NCMP returning EMS jobs Rafael Rocha to update documentation. Agreed, should be defined from client side. NCMP to define DOD for NCMP point | Toine |
| 4 | Section 3.2.3 Page 23. Step 10. Who is calculating percentage. Is percentage realistic. Does NCMP need to be able to amalgamate?! | Taken, NCMP will only pass through what ever has been communicated through.....this should be rediscussed and discouraged the use of % may not accurately represent the true result and datas Rafael Rocha to revisit Rafael to discuss with Kieran/Csaba ...... How does this affect the current data job requirement (requirement 1,2,3)....DCM should have this, According to study author, it's proposed they shouldn't be any impact on the current implementation proposal frm NCMP on epic, 1,2,and 3 so far. NCMP requesting for an updated study with latest discussion/agreement a proposed by study author. It's an optional attribute | Toine |
| 5 | Section 3.2.4 Page 24. Step 10. 'Write' instead of read. But same question as for previous uses case re NCMP and Amalgamation of status | DMI plugin are expected to send these request. What are the output expected in the write usecase ? Some examples are provided on the appendix (10.1.4) for write/read CRUDAQ NCMP is not expected to change/review/go into these responses ..... NCMP are ONLY expected to forward these responses from a datajob, they are coming ENM. DCM is responsible for the update of these status. During S3 implementation NCMP are now expected to STORE these request. | Toine |
| 6 | Section 3.3.2.3 Page 31/32 Delete MO (with) Children, you have 2 bullets for this but I don't think deletion WITHOUT delete any children present is impossible.... I see later you mention BASE_NTH_LEVEL option but this seems very strange to me , a client is hardly going to delete all 4-th 'generation' children without specifying the paths to their parent. Seems very unsafe to me. Maybe I am misunderstanding what is intending here. Using a 'level of descendants' makes sense in read operations but not in delete. |
| Toine |
| 7 | Section 3.3 Page 25. 'Atomic Operation' what is intended here since we are talking about 'Single resource' Please explain | This is a sync interface, there shouldn't be partial result, it's all or nothing | Toine |
| 8 | Section 3.3 Page 26. 'DCM Not involved' Is DCM not a wrapper for NCMP libraries now? then this statement does not make sense! This comment applies to quiet a few steps actually... | No implementation for the sync, DCM is not a wrapper for all the interfaces. Note, DCM = CPS E-10 | Toine |
| 9 | Section 3.3.2 Page 28. I am confused about REST layer since the proposed URLS are NOT using Open SOURCE NCMP names! If DCM (Ericsson team) is responsible for REST layer and NCMP Libraries Service libraries are used for implementation but NOT any NCMP REST interface i.e. CPS Team is not impacted by REST interface definition in this document | Taken | Toine |
| 10 | 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 | CPS shall be responsible for implementing NCMP interface including the new 3GPP sync rest interface. We'll publish all rest API available in the open source. This will be reused by EIC. It was also concluded that functional, end to end testing is the responsibility of NM engineering Teams. | `Toine |
| 11 | Section 3.3.3. Page 37. 'destination' is non mandatory but no default is defined in the table. (same comments for several operations) | E-11, will be worked on from EIC. Who validate this ? ... What type of validation ? ... could be done in rest layers, enums ncmp currently does some validation in service layers. needs to be agreed during requirement gathering, Rafael Rocha study should also convey what's expected/agreed. | Toine |
| 12 | Section 3.3.5. Page 42. Progress Percentage. As mentioned before I think we need to discuss how this is going to be defined. Is it based on number of ENMS involved, number of CM Handles ?! Not suer how this will work especially when targeting subnetworks etc. | see # for responses. | Toine |
| 13 | Section 3.4.1. Page 44. Can you add notes that Alternate ID is unique and once set it cannot be changed. (or in section 3.4.3 ?) | Alternate ID is unique and once set it cannot be changed | Toine |
| 14 | Section 3.8.2. Interface Impacts Page 55. Add new interface (or do we want all to fall under existing CPS-E-05, I prefer more granular interface names | see updated doc from Rafael. Toine proposed interface name agreed from NCMP perspective. | Toine |
| 15 | Section 4.2.2.5 Page 62. Definition of Done. Similarly: Upon registration of a duplicate FDN an Alarm will be raised (its a minor comment and applies to many DoDs I wont comment again and you don't have to update I think the intention is clear. I also saw that in section 4.3 the DoDs are written in the correct format) | see #3 | Toine |
| 16 | Section 4.3.3. Page 82. Included proposed name of new interface | see #14 | Toine |
| 17 | Section 4.3.4.4. Scope Page 84. Need to clarify more detailed which interface is targeted here! | Toine | |
| 18 | Section 4.3.5. Page 85. Included proposed name of new interface | Toine | |
| 19 | Section 4.3.5.4. Scope Page 85. Remove note about non-uniqueness of FDN | Agreed with stakeholders duplicated FDNs will be rejected. So alternateId will only contain unique FDN values None uniqueness of alternateid Kolawole Adeolokun | Toine |
| 20 | Section 4.3.5.5. Definition of Done Page 85. Refers to existing interfaces? This item is for a NEW interface | Toine | |
| 21 | Section 4.3.6.4. Scope Page 86. Need to clarify more detailed which interface is targeted here! Probably needs its own small study. Only once this is clear we can start estimating costs. | Toine | |
| 22 | Is there a difference between a Managed Object and a Managed Element? | Managed Element - Representation of the device in ENM, Basically it's the root. | |
| 23 | What is an S3 bucket and what is its purpose in the system? | majorly for the asych use case, publishing result, see, get in Kafka and S3 working as a datastore (Minio) | |
| 24 | What is BDR and what is its purpose in the system? | Scope data repo, similar to S3, for publishing result. Bulk data repo. | |
| 25 | Is the DMI Plugin Ericsson propriety or the ONAP component? | ncmp defines dmi interface, EIC have thier own propriety interface | |
| 26 | What form does an FDN take exactly? | FDN example : Subnetwork=22,MeContext=Kista,ManagedElement=Kista,GNBDUFunction=1,UECC=1 or URI FDN example : /Subnetwork=22/MeContext=Kista/ManagedElement=Kista/GNBDUFunction=1/UECC=1 Should be compliant with 3GPP, refer to Kieran shared doc for further update. ' / ' Agreement needed for what NCMP use of / or , for consistency and conversation ....... use url starting with a / .... Rafael study should indicate this | |
| 27 | What are M-Plane and O1 devices? | M-plane = radio units and 01 These are network elements used in O-RAN for communicating. Proven MNS is what our interfaces will be using...... | |
| 28 | Does the current infrastructure change for DCM or is DCM merely an extension of NCMP? Can we access documentation on the current system infrastructure and the components therein? | CPS shall be responsible for implementing NCMP interface including the new 3GPP sync rest interface. We'll publish all rest API available in the open source. This will be reused by EIC. It was also concluded that functional, end to end testing is the responsibility of NM engineering Teams. Implementation still needs to be discussed during implementation of Support for Async datajob |
Overview
Proposed Epics
Proposed Steps for ONAP (CPS NCMP) are described in Section 4.3
Section | ||||||
|---|---|---|---|---|---|---|
Section | ||||||
| 4.3.1 | Register alternate identifier (incl. update) | Small (2-4 pw) | CPS-NCMP-I-01 | IN PROGRESS | ||
| 4.3.2 | Update NCMP events to populate alternate id | X-Small (1 pw) | Which event(s) exactly? Assumed just CmHandle LCM | CPS-E-08.e | CPS-2007 | IN PROGRESS |
| 4.3.3 | Support for Async Data Jobs | X-Large | NCMP Java impacts only, DCM will implement new interface (not open source)
| DCM-? (new) | CPS-1964 | IN PROGRESS |
| 4.3.4 | Update existing single sync cm handle APIs to support alternative id (populated with FDNs) | Medium | Includes SubNetwork 'cm handles' ie. NCMP needs to resolve to best match knowing the 3GPP 'patterns' used by ericsson (hardcoded)
| CPS-E-05 | CPS-2008 | NOT STARTED |
| 4.3.5 | NCMP to support new 3GPP sync single FDN request | Large | Question: can this interface be delivered as a separate OpenAPI defintion? | CPS-E-10 (new) | CPS-1992 | NOT STARTED |
| 4.3.6 | Update remaining existing/legacy NCMP APIs to support alternative id (FDN) | Large | Need study to see which interfaces are exactly impacted. Not all interfaces might be relevant for ericsson use cases. | CPS-E-05 | CPS-2009 | NOT STARTED |
| 4.3.7 | NCMP to support data job results in S3 | Medium | NCMP Java impacts only, DCM will implement interface impacts (not in open source) Although 'S3' is an unknown component for the team we assume it has a well define easy to use API | DCM-? (same as for 4.3.3.) | CPS-2010 | NOT STARTED |