CPS-1733: Upgrade YANG schema-set for CM handle using a ModuleSet Tag

CPS-1733 - Getting issue details... STATUS

CPS-1734 - Getting issue details... STATUS

Study is required to clearly define the scope and impacts of updating YANG model schema sets for cm-handles. 

Requirements

Functional

Error Handling

Characteristics

Out-of-scope

• Upgrade of models for cached data. "ncmp-datastore:operational" is out-of-scope.  

 Note: Only pass-through i.e. non-cached data upgrade is in scope; "ncmp-datastore:passthrough-running" and "ncmp-datastore:passthrough-operational" is in scope.

Assumptions

Issues & Decisions

Solution Proposals 

Toine Siebelink Can you alternative proposals be maintained (kafka) so we know they were considered and reviewed and ruled out.  Be good to see what was reviewed/considered.

Update Inventory REST Interface

Making the module upgrade request either over REST or Kafka Event with a supplied 'moduleSetTag' property will indicate to NCMP that a cmhandle has a new moduleSet (node has been upgraded).  The moduleSetTag is a unique identifier 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 moduleSetTag as part of a previous retrieval for a set of modules for a cmhandle that supplied this moduleSetTag then it should not re-retrieve the modules from the dmi plugin as it already has them.  NCMP should use its stored moduleSetTag 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 moduleSetTag supplied by a dmi-plugin (during and updateCmHandles request) and the modules.  Initially moduleSetTag 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 moduleSetTag will not require NCMP to go back to the dmi plugin for the moduleSet.

Reuse the NCMP Inventory API (CPS-NCMP-I-01). URI : POST /v1/ch

{
    upgradedCmHandles : [      
      {
         "cmhandle" : "<cmhandle-id-1>",
         "moduleSetTag" : "ffsdfg55342"   #  new moduleSetTag ffsdfg55342 for the cmhandle        },       
      {
         "cmhandle" : "<cmhandle-id-2>",
         "moduleSetTag" : "ffsdfg55342"   #  new moduleSetTag ffsdfg55342 for the cmhandle        },     
      { 
         "cmhandle" : "<cmhandle-id-3>",    
         "moduleSetTag" : "ddger34324"    #  new moduleSetTag ddger34324 for the cmhandle         }
  ]
}

Support for upgrade without (empty) moduleSetTag

If the moduleSetTag json property is set to "" (empty string) or then it should also indicate that the moduleSet for a cmhandle has been updated but there is no associated moduleSetTag available for that cmhandle.  This approach will always result is a full request to the dmi plugin for the module set for the cmhandle.

Suggested User Stories

1. Define (in Open API )and agree inventory interface (changes)  for 'upgradedCmHandles'
2. Update Inventory Model to store 'ModuleSetTag' (Liquibase set incl rollback) 
3. Implement upgrade
4. (Check) Locking/notifications state handling (some modifications might be needed)
5. Implement/test error scenarios
6. Test & Document performance
7. Implement ModuleSetTag for Initial Inventory

Proposed JIRAs