- CPS-1733Getting issue details... STATUS
Study is required to clearly define the scope and impacts of updating YANG model schema sets for cmhandles.
Requirements
Functional
# | Interface | Requirement | Additional Information |
---|---|---|---|
1 | TBD |
Error Handling
# | Error Scenario | Expected behavior |
---|---|---|
1 |
Capabilities
The assumption is there are 100 modules in each moduleSet and a moduleSet is available from a dmi plugin within 0.5 seconds. Also assume there is a 90% overlap in modules across all CM Handles.# Parameter Expectation Notes 1 Request Frequency
Upgrade to NEW moduleSetIds2.5 upgrades / second → 150 upgrades / minute 2 Request Frequency
Upgrade to already existing moduleSetIds5 upgrades / second → 300 upgrades / minute 3 Test Environment 4 Concurrent request TBD 12 clients requests toward 1 NCMP simultaneously
Out-of-scope
- Upgrade of models for cached data (only pass-trough ie. non-cached data upgrade will be supported
Issues & Decisions
# | Issue | Notes | Decision |
---|---|---|---|
1 | Type of Interface REST or Kafka | REST
Kafka
| |
2 | ModuleSetId based on Hash no (yet) implemented | This study seems to assume the hash-based module id is already implemented but it isn't! |
Solution Proposals
Two options to trigger a module set upgrade. One based on kafka events and one based on REST. Preference is alternative 1 - the Kafka based solution.
Making the module upgrade request either over REST or Kafka Event with a supplied 'moduleSetId' property will indicate to NCMP that a cmhandle has a new moduleSet (node has been upgraded). The moduleSetId is a unique identifier (hash!) for the set of modules associated with a cmhandle. This event or rest request will trigger ncmp to either retrieve the new module set for this cmhandle from the dmi plugin or if NCMP is already aware of moduleSetId as part of a previous retrieval for a set of modules for a cmhandle that supplied this moduleSetId then it should not re-retrieve the modules from the dmi plugin as it already has them. NCMP should use its stored moduleSetId to get the set of modules. It can then do a delta with the existing cmhandle moduleSet and update the moduleSet for the cmhandle.
The above proposal would require model updates to NCMP to store the association between a moduleSetId supplied by a dmi-plugin (during and updateCmHandles request) and the modules. Initially moduleSetId is not known to NCMP. However, after retrieval of the modules for the first time for the cmhandle, NCMP can store the association. Any subsequent cmhandle that references the same moduleSetId will not require NCMP to go back to the dmi plugin for the moduleSet.
Alternative 1 : Kafka based solution
Scenario : a node has been upgraded. This should trigger a new set of modules to be registered for the cmhandle in NCMP.
DMI Plugin -> NCMP : Events sent from DMI Plugin to NCMP
Kafka Topic : CMHandleProperties (new)
Kafka Event : org.onap.cm.events.module-set-change-event
<cloudEvents-header> id : <cmhandleId> type : org.onap.cm.events.module-set-change-event data : { "moduleSetId" : "689fhdsd88dddwde" }
Alternative 2 : Rest based solution
Reuse the NCMP Inventory API (CPS-NCMP-I-01).
URI : POST /v1/ch
Request Body
{ updatedCmHandles : [ { "cmhandle" : "<cmhandle-id-1>", "moduleSetId" : "ffsdfg55342" # new moduleSetId ffsdfg55342 for the cmhandle }, { "cmhandle" : "<cmhandle-id-2>", "moduleSetId" : "ffsdfg55342" # new moduleSetId ffsdfg55342 for the cmhandle }, { "cmhandle" : "<cmhandle-id-3>", "moduleSetId" : "ddger34324" # new moduleSetId ddger34324 for the cmhandle } ] }
Additional Information
If the moduleSetId json property is set to "" (empty string) or then it should also indicate that the moduelSet for a cmhandle has been updated but there is no associated moduleSetId available for that cmhandle. This approach will always result is a full request to the dmi plugin for the module set for the cmhandle.