- CPS-1733Getting issue details... STATUS
- CPS-1734Getting issue details... STATUS
Study is required to clearly define the scope and impacts of updating YANG model schema sets for cm-handles.
Requirements
Functional
# | Interface | Requirement | Additional Information | Sign Off |
---|---|---|---|---|
1 | CPS-NCMP-I-01 | Upgrade module set for CM-Handle(s) using a moduleSetTag | Module Set Tag is owned (defined) by DMI Plugin |
|
2 | CPS-NCMP-I-01 | Initial Inventory shall support (Optional) moduleSetTag too | Exiting performance shall not degrade. |
|
3 | CPS-NCMP-I-01 | Update module set for CM-Handle(s) using a Blank (not defined) moduleSetTag | use 'old' algorithm from initial inventory |
|
4 | CPS-E-05 | Read moduleSetTag for given CM Handle(id) | Probably no code changes required (just a model change) |
|
5 | CPS-E-05 | Query Cm Handle(s) using CPS Path with moduleSetTag | Probably no code changes required (just a model change) |
|
6 | CPS-E-05.e (e for events) | A new notification informing the client the old and new value of moduleSetTag | Use same topic as CM Handle LCM Events (and future trust-level change notifications) |
|
Error Handling
# | Error Scenario | Expected behavior | Sign-off |
---|---|---|---|
1 | Missing CM Handles (in list, some are OK) | Similar to 'Initial Inventory' i.e response should include list of 'failed' cm handles | |
2 | Upgrade request for 'cached' data (cache enabled) | Refuse request; not supported |
Characteristics
The assumption is there are 100 modules in each moduleSet and a moduleSet is available from a dmi plugin within 0.5 seconds. Also assume there is a 90% overlap in modules across all CM Handles.# Parameter Expectation Notes 1 Request Frequency
Upgrade to NEW moduleSetTags3 upgrades / second → 180 upgrades / minute 2 Request Frequency
Upgrade to already existing moduleSetTags6 upgrades / second → 360 upgrades / minute 3 Test Environment 4 Concurrent request 12 clients requests toward 1 NCMP simultaneously 5 Number of CM Handles in one request
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 |
---|
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 | 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 possibly could be done as part of 'updatedCmHandles' and look for /recognize the moduleSetTag update but this would be messy and confusing, also then theoretically 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 notification see requirement #6 |
Solution Proposals
Update Inventory REST Interface
Making the module upgrade request either over REST or Kafka Event with a supplied 'moduleSetTag' property will indicate to NCMP that a cmhandle has a new moduleSet (node has been upgraded). The moduleSetTag is a unique identifier 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 moduleSetTag as part of a previous retrieval for a set of modules for a cmhandle that supplied this moduleSetTag then it should not re-retrieve the modules from the dmi plugin as it already has them. NCMP should use its stored 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 moduleSetTag supplied by a dmi-plugin (during and updateCmHandles request) and the modules. Initially 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 moduleSetTag will not require NCMP to go back to the dmi plugin for the moduleSet.
Reuse the NCMP Inventory API (CPS-NCMP-I-01). URI : POST /v1/ch
Support for upgrade without (empty) moduleSetTag
If the moduleSetTag json property is set to "" (empty string) or then it should also indicate that the moduleSet for a cmhandle has been updated but there is no associated 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.
Proposed JIRAs
Priority | Component | Description | JIRA | Estimates |
---|---|---|---|---|
1 | NCMP | Update existing REST endpoint add operation to upgrade YANG schema set using moduleSetTag | 15 Days | |
2 | NCMP | Upgrade inventory YANG model to store moduleSetTag | 5 Days | |
3 | NCMP | Update cmhandle state (lock) during YANG model upgrade | 5 Days | |
4 | NCMP | Modify existing inventory operations using moduleSetTag as optional attribute | 15 Days | |
5 | NCMP | Identify and test error scenarios | 5 Days | |
6 | NCMP | Update DMI Stub for testing purposes and add CSIT test | 5 Days | |
7 | NCMP | Test and document performance of updating YANG schema set API. | 10 Days |
Planning:
- Allow for 2 more user stories each may take 1 week.
- Estimated date of completion is based on 2 resources working parallelly.
- These are estimates and should not be interpreted as commitments.