...
Study is required to clearly define the scope and impacts of updating YANG model schema sets for cmhandles.
| Table of Contents |
|---|
Requirements
Functional
| # | Interface | Requirement | Additional Information |
|---|---|---|---|
| 1 | TBD |
Error Handling
| # | Error Scenario | Expected behavior |
|---|---|---|
| 1 |
Capabilities
| Excerpt | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Out-of-scope
- Upgrade of models for cached data (only pass-trough ie. non-cached data upgrade will be supported
Issues & Decisions
| # | Issue | Notes | Decision | ||||
|---|---|---|---|---|---|---|---|
| 1 | Type of Interface REST or Kafka | REST
Kafka
kieran mccarthy : Understood REST is more aligned with existing registration interface. It is however less robust though. For example if NCMP crashes it would be preferable to just continue by pulling next request from topic. Will check with design and come back | Agreed to use REST interface. | ||||
| 2 | ModuleSetTag | 2 | ModuleSetIdbased on Hash no (yet) implemented! | This study seems to assume the | hash-based module | id set tag is already implemented but it isn't! | kieran mccarthy : the request it to introduce the hash for this new 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?
| |||||
| 4 | Should CM-Handle state cahnge (ie to lockedchange (e.g. to 'locked') 'during' upgrade? | Yes but is important to not be locked for long which makes it important to use the hashtag | |||||
| 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 | |||||
| 6 | ModuleSetTag should be able to be used during initial inventory too! | Initial Inventory should be sped up too (capability requirements impacts ?!) | |||||
| 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 |
Solution Proposals
...
Update Inventory REST Interface
Making the module upgrade request either over REST or Kafka Event with a supplied 'moduleSetIdModuleSetTag' property will indicate to NCMP that a cmhandle has a new moduleSet (node has been upgraded). The moduleSetId ModuleSetTag is a unique identifier (hash!) for the set of modules associated with a cmhandle. This event or rest request will trigger ncmp to either retrieve the new module set for this cmhandle from the dmi plugin or if NCMP is already aware of moduleSetId ModuleSetTag as part of a previous retrieval for a set of modules for a cmhandle that supplied this moduleSetId ModuleSetTag then it should not re-retrieve the modules from the dmi plugin as it already has them. NCMP should use its stored moduleSetId ModuleSetTag to get the set of modules. It can then do a delta with the existing cmhandle moduleSet and update the moduleSet for the cmhandle.
The above proposal would require model updates to NCMP to store the association between a moduleSetId ModuleSetTag supplied by a dmi-plugin (during and updateCmHandles request) and the modules. Initially moduleSetId ModuleSetTag is not known to NCMP. However, after retrieval of the modules for the first time for the cmhandle, NCMP can store the association. Any subsequent cmhandle that references the same moduleSetId ModuleSetTag will not require NCMP to go back to the dmi plugin for the moduleSet.
Alternative 1 : Kafka based solution
Scenario : a node has been upgraded. This should trigger a new set of modules to be registered for the cmhandle in NCMP.
DMI Plugin -> NCMP : Events sent from DMI Plugin to NCMP
Kafka Topic : CMHandleProperties (new)
Kafka Event : org.onap.cm.events.module-set-change-event
...
.
...
Alternative 2 : Rest based solution
Reuse the NCMP Inventory API (CPS-NCMP-I-01). URI : POST /v1/ch
| Code Block | ||||
|---|---|---|---|---|
|
...
|
...
| |
{
|
...
upgradedCmHandles : [ { "cmhandle" : "<cmhandle-id-1>", " |
...
ModuleSetTag" : "ffsdfg55342" # new |
...
ModuleSetTag ffsdfg55342 for the cmhandle }, { "cmhandle" : "<cmhandle-id-2>", " |
...
ModuleSetTag" : "ffsdfg55342" # new |
...
ModuleSetTag ffsdfg55342 for the cmhandle }, { "cmhandle" : "<cmhandle-id-3>", " |
...
ModuleSetTag" : "ddger34324" # new |
...
ModuleSetTag ddger34324 for the cmhandle } ] } |
...
Support for upgrade without (empty) ModuleSetTag
...
If the moduleSetId ModuleSetTag json property is set to "" (empty string) or then it should also indicate that the moduelSet moduleSet for a cmhandle has been updated but there is no associated moduleSetId ModuleSetTag available for that cmhandle. This approach will always result is a full request to the dmi plugin for the module set for the cmhandle.
...