Page History

...

Basically the same steps as during initial inventory can be followed. Except the creation of the cmHandle (anchor) as that already exist.
Refer to org.onap.cps.ncmp.api.inventory.sync.ModuleSyncTasks#performModuleSync for the relevant code

1. get all module references from the (upgraded) cm handle (via DMI)
2. find out which module references are NEW to CPS-Core
3. get the yang resources for the new modules from the (upgraded) cm handle (via DMI)
4. create/save a new (TBC, issue #12) schema set using the existing module reference and new yang resources
5. (proposed name for schema set: <cmHandleId>-<moduelSetTag> TC see issue #12)update the schemaset new) update the schema set for the upgraded cm handle
6. (new) set the moduleSetTag in the ncmp inventory for the upgraded cm handle (mabey this needs to be done at the start?)
7. (new) TBC delete the old schema set of the upgraded cm handle (depend on decision re issue #12)

Use ModuelSyncWatchDog (parallel processing)

Initial inventory is driven by (batches of) Cm Handle state changes on the main thread and then the org.onap.cps.ncmp.api.inventory.sync.ModuleSyncWatchdog processes those!

Examining this in detail lead to some additional design questions

1. should upgrade be dealt with in parallel too? Toine Siebelink recommends this
2. should upgrade be done in batches (of 100) too?
3. need to use a (new?) state for UPGRADE that the watchdog can see an process
4. re-use existing methods and make creating aan anchor optional or create new upgrade specific methods and reuse/slightly duplicate initial inventory methods? Methods like
   1. org.onap.cps.ncmp.api.inventory.sync.ModuleSyncService#syncAndCreateSchemaSetAndAnchor
   2. org.onap.cps.ncmp.api.inventory.sync.ModuleSyncService#createSchemaSetAndAnchor

Proposed JIRAs

...