...
| Excerpt | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Out-of-scope
- Upgrade of models for cached data. "ncmp-datastore:operational" is out-of-scope.
...
| # | 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 | kieran mccarthy and team. |
| 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 mention "upgrade" and have the usual timestamps. A separate notifications will be send with details of the old and new values for moduleSetTag see decision #11 |
| 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 | kieran mccarthy and team. Yes, if need backward incompatible change can be handle as a new version of the interface |
| 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 |
| Part of requirement listed above, to be finalized in a meeting after the holidays on |
| 11 | Separate Notification on change of moduleSetTag |
| kieran mccarthy separte separate notification see requirement #6 |
...
| Code Block | ||||||||
|---|---|---|---|---|---|---|---|---|
| ||||||||
module dmi-registry {
yang-version 1.1;
namespace "org:onap:cps:ncmp";
prefix dmi-reg;
contact "toine.siebelink@est.tech";
revision "2023-08-23" {
description
"Added ModuleSetTag";
}
revision "2022-05-10" {
description
"Added DataSyncEnabled, SyncState with State, LastSyncTime, DataStoreSyncState with Operational and Running syncstate";
}
revision "2022-02-10" {
description
"Added State, LockReason, LockReasonDetails to aid with cmHandle sync and timestamp to aid with retry/timeout scenarios";
}
revision "2021-12-13" {
description
"Added new list of public additional properties for a Cm-Handle which are exposed to clients of the NCMP interface";
}
revision "2021-10-20" {
description
"Added dmi-data-service-name & dmi-model-service-name to allow separate DMI instances for each responsibility";
}
revision "2021-05-20" {
description
"Initial Version";
}
grouping LockReason {
leaf reason {
type string;
}
leaf details {
type string;
}
}
grouping SyncState {
leaf sync-state {
type string;
}
leaf last-sync-time {
type string;
}
}
grouping Datastores {
container operational {
uses SyncState;
}
container running {
uses SyncState;
}
}
container dmi-registry {
list cm-handles {
key "id";
leaf id {
type string;
}
leaf dmi-service-name {
type string;
}
leaf dmi-data-service-name {
type string;
}
leaf dmi-model-service-name {
type string;
}
leaf module-set-tag {
type string;
}
list additional-properties {
key "name";
leaf name {
type string;
}
leaf value {
type string;
}
}
list public-properties {
key "name";
leaf name {
type string;
}
leaf value {
type string;
}
}
container state {
leaf cm-handle-state {
type string;
}
container lock-reason {
uses LockReason;
}
leaf last-update-time {
type string;
}
leaf data-sync-enabled {
type boolean;
default "false";
}
container datastores {
uses Datastores;
}
}
}
}
} |
...
Upgrade With Module Set Tag
- Use new 'upgradedCmHandles' operation to upgrade CH-1
- Find a cmHandle with given 'moduleSetTag'
(if not found use algorithm defined in next section) - Get all module references for cm handle (schemaset) with same tag (CH-2)
- Update module references for the anchor/schemaset CH-1
- Update inventory for CH-1 with given module set tag
Support for Upgrade Without Module Set Tag
Note. Same algorithm should be used when Moduel Set tag is blank or no oterh CMHanlde with same tag can be found
If the moduleSetTag json property is set to "" (empty string) or then it should also indicate that the moduleSet for a cmhandle cmHandle has been updated but there is no associated moduleSetTag available for that cmhandlecmHandle. This approach will always result is a full request to the dmi plugin for the module set for the cmhandlecmHandle.
Proposed JIRAs
| Priority | Component | Description | JIRA | Estimates | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | CPS Core | Expose a java interface to update schema set |
| 5 Days | ||||||||||||
| 2 | NCMP | Update existing REST endpoint add operation to upgrade YANG schema set using moduleSetTag |
| 15 Days | ||||||||||||
| 3 | NCMP | Upgrade inventory YANG model to store moduleSetTag |
| 5 Days | ||||||||||||
| 4 | NCMP | Upgrade anchor to new yang schema set |
| 5 Days | ||||||||||||
| 5 | NCMP | Update cmhandle state (lock) during YANG model upgrade |
| 5 Days | ||||||||||||
| 6 | NCMP | Modify existing inventory operations using moduleSetTag as optional attribute |
| 15 Days | ||||||||||||
| 7 | NCMP | Identify and test error scenarios |
| 5 Days | ||||||||||||
| 8 | NCMP | Update DMI Stub for testing purposes and add CSIT test |
| 5 Days | ||||||||||||
| 9 | NCMP | Test and document performance of updating YANG schema set API. |
| 10 Days |
...