Page History

...

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.

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

Proposed JIRAs

...