...
| # | Error Scenario | Expected behavior |
|---|
| 1 |
|
|
Capabilities
| Excerpt |
|---|
Characteristics : ++ - It shall be possible to upgrade moduleSets for cmhandles at a rate of 2.5 / second when the moduleSetIds are unknown to NCMP. ***
- It Shall be possible to upgrade moduleSets for cmhandles at a rate of 5 / second when the provided moudleSetIds are already known to NCMP.
*** | # | Parameter | Expectation | Notes |
|---|
| 1 | Request Frequency
Upgrade to NEW moduleSetIds | 2.5 upgrades / second → 150 upgrades / minute | 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. |
|---|
| 2 | Request Frequency
Upgrade to already existing moduleSetIds | 5 upgrades / second → 300 upgrades / minute |
|
|---|
| 3 | Test Environment |
| Expand |
|---|
- CPS and NCMP
requests:
cpu: 2000m
memory: 2Gi
limits:
memory: 3Gi
cpu: 3000m
2. Postgres requests:
cpu: 4000m
memory: 1Gi
limits:
memory: 3Gi
cpu: 6000m
|
|
|
|---|
| 4 | Concurrent request | TBD | 12 clients requests toward 1 NCMP simultaneously |
|---|
|
...
- 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
- easier/cheaper
- well documented by OpenAPI
- support test stubs (contract testing)
Kafka - more complicated/costly
- plethora of topics and messages, not well documented (no standard)
- More robust (request persisted until acknowledged)
| |
|---|
| 2 | ModuleSetId based on Hash no (yet) implemented | This study seems to assume the hash-based module id is already implemented but it isn't! |
|
|---|
Solution Proposals
Two options to trigger a module set upgrade. One based on kafka events and one based on REST. Preference is alternative 1 - the Kafka based solution.
...
