...
| Excerpt | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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
| # | Assumption | Notes |
|---|---|---|
| 1 | Client will be informed of upgrade by 'state-change' notifications |
Issues & Decisions
| # | Issue | Notes | Decision |
|---|---|---|---|
| 1 | Type of Interface REST or Kafka | REST
Kafka
| meeting Agreed to use REST interface. |
| 2 | moduleSetTag based on Hash no (yet) implemented! | This study seems to assume the module set tag is already implemented but it isn't! | [kieran mccarthy]: the request it to introduce the module set tag/identifier of some kind for this new upgrade usecase. Not assuming it is there already. Will be costlier but is important for performance to avoid pulling models if they are already known to NCMP. |
| 3 | Expected Responses | when and what content?
Should follow error handling for Inventory | 202 Accepted if there are no issues with the payload 404 Not Found Reject the request if an unknown cmhandle is sent in TBD partial correct cm hanldes |
| 4 | Should CM-Handle state change (e.g. to 'locked') 'during' upgrade? | Yes but is important to not be locked for long which makes it important to use the moduleSetTag | kieran mccarthy Should be set to LOCKED until the new moduleSet is associated with the cmhandle. I think there is a LOCKED_UPGRADING if I remember right. Lock reason should state "upgrade initiated at time xxx for new moduleSetTag xyz". When lock is being removed any lockReason message should be cleared. |
| 5 | moduleSetTag is Optional (owned and defined by DMI Plugin) | Support for upgrade without continues using delete/add cm handle approach. If the update includes an moduleSetTag it would be considered an upgrade | meeting Agreed to use REST interface with "upgradedCmHandles". |
| 6 | moduleSetTag should be able to be used during initial inventory too! | Initial Inventory should be sped up too (capability requirements impacts ?!) Note. Current inventory 'createdCmHandles' only supports a list of cm handle Ids can this be in backward compatible way be modified to optionally include a ModuleSetTag | |
| 7 | Exact name moduleSetTag | meeting agreed on moduleSetTag | |
| 8 | How to store: hardcoded (postgress schema), inventory yang model or as additional property (private or public)? | update Inventory Yang Model so it can be queried (without code changes!) like other aspect such as 'state' | meeting agreed to update Yang Model |
| 9 | additional operation for inventory Interface: 'upgradedCmHandles' | The interface currently supports
it possiblycould be done as part of 'updatedCmHandles' and look for /recognize the moduleSetTag update but this would be messy and confusing, also thentheoretically properties could be updated as the same time as the module set.. | meeting agreed |
| 10 | Clarify capabilities |
| |
| 11 | Separate Notification on change of ModuleSetTag |
|
...