Page History

...

Out-of-scope

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

...

1. Need to use a new (shared) Hazelcast map with ModuleSetTags as key (value list of module refs) that have been processed (but not saved yet) to be used both inside a batch and different instance to prevent unnecessary trips to DMI/Node
2. Watchdog needs to use Lock state AND lock reason to determine what node need to be upgraded
3. Initial inventory and upgrade is not likely to happen at the same time but watchdog can handle both, of course performance would be affected if that does occur
4. CACHE(s) needs to be cleared or updates as algorithm wil re-use existing schema set name
5. Create new upgrade specific methods and reuse/slightly duplicate initial inventory methods
6. Legacy (and new) checks for lock need to check the lock-reason too now! To differentiate between failed initial inventory and upgrade
7. Probably need more specific (new) failure reasons to differentiate between initial inventory and upgrade failures
8. as usual: small commits, early reviews to introduce all this functionality are advised, posisbel steps
   1. set lock state and reason upon request
   2. watch dog just list to be upgrade node (and does not mix them up with failed initial inventory)
   3. perform first upgrade for a new ModuleSetTag
   4. introduce and use new Hazelcast map
   5. perform upgrade of an node with a modueleSetTag that is already in cache
   6. perform upgrade of an node with a modueleSetTag that is already in DB (ie introduce DB query)
   7. handle failure of upgrade (re-use same retry mechanism as initial inventory but with different lock reason!)
   8. etc.

Proposed JIRAs

Use-Case Overview (Sync in watchDog)

Note. Error handling like invalid IDs are handled during the Synchronous part of registration and not part of this use-case overview. 
Upgrade to the same Tag should be captured in synchronous pre-processing.

re-usable methods

1. Gget modules (delta) from Node (DMI)
2. Create schemaset. Combination of exiting Refs and new yang resources
   New yang resources empty for known module sets (known tag)
3. Create anchor
4. Update schemaset. Combination of exiting Refs and new yang resources
   New yang resources empty for known module sets (known tag)

Changes agreed 15 Feb 2024 between Daniel Hanrahan , Sourabh Sourabh and Toine Siebelink 

void processCreate() {
   if (tagProvided && tag in DB) {
          allModuleRefences = referencesFromDb
          newYangResources = []
       else {
          delta = getModulesDelta()
          newYangResources = delta.newYangResources 
          allModuleRefences = delta.allModuleRefences 
    }
    creatSchemaSet(newYangResources,  allModuleRefences)
    createAnchor()
}       
     
void processUpgrade() {
    if (tagProvided && tag in DB) {
          allModuleRefences = referencesFromDb
          newYangResources = []
       else {
          delta = getModulesDelta()
          newYangResources = delta.newYangResources 
          allModuleRefences = delta.allModuleRefences 
    }
    udpateSchemaSet(newYangResources,  allModuleRefences)
}

Proposed JIRAs

Planning:

• Allow for 2 more user stories each may take 1 week. 
• Estimated date of completion is  15 Nov 2023 based on 1 person working. There is a possibility that 1 more person will join in between for implementation but there is no clear visibility on when the person can start contributing as of now. 
• These are estimates and should not be interpreted as commitments. 

...