...
# | 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.
...