References
Jira Legacy server System Jira columnIds issuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key CPS-872 - CPS-799 Spike: Define states and state handling for CM handle
Tasks
NCMP should be able to handle a large (10,000s!) batch of registrations at once. To make this possible we need to
| Task | |
|---|---|
| 1 | Create updated DMI Registry Yang Schema (using @yyyy-mm-dd) in changelog/db/changes/data/yang-models/dmi-registry @ 2021-12-13.yang to store Handle State |
| 2 | Add State, LockReason and LockReasonDetails as (Yang)Strings to the schema. Any validation or enum-limitations can be handled in the Java code. |
| 3 | Consider timestamp modelSyncStartTime for last-update-time for retry and timeout related scenarios as part of same schema update to reduce overhead of Liquibase changesets |
| 4 | Test/demo using CPS-Core
|
Yang Revision Proposal
- Reordered the revision tags based on reverse chronical order convention
- Added state leaf to hold the synchronization state information
- Added lock-reason leaf to hold a lock reason enum
- Added lock-reason-details leaf non enum description of lock reason. More descriptive and scenario based.
- Added model-sync-start-time to hold the start time of when the most recent sync attempt on this cmHandle was started.
- https://gerrit.onap.org/r/c/cps/+/127060/5/cps-ri/src/main/resources/changelog/db/changes/data/yang-models/dmi-registry%25402022-02-10.yang
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
module dmi-registry {
yang-version 1.1;
namespace "org:onap:cps:ncmp";
prefix dmi-reg;
contact "dylan.byrne@est.tech";
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";
}
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;
}
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;
}
}
leaf state {
type string;
}
leaf lock-reason {
type string;
}
leaf lock-reason-details {
type string;
}
leaf modellast-sync-startupdate-time {
type string;
}
}
}
}
|
...
Propose and agree new model with team and stakeholders
...
- Can create anchor using new model
- Can add data for new model
- Can query data using file based on state
...
...
Agree new name for dataspace. Replace Admin dataspace?
...
Describe impacts to codebase
Timestamp
...
Timestamp
last-update-time will be recorded once model/data sync attempt is started and will be removed once model sync is completed. CmHandle state should be changed from advised to locked during sync. Extending the query from ncmp to look for cmHandle state and modelSyncStartTime would remove need for watchdog.
Prevention of multiple NCMP attempting sync
It is possible for multiple NCMP instances to attempt to sync the same cmHandle from the singular cps instance. In order to prevent this we can implement an exclusive lock using the PESSIMISTIC_WRITE JPA locking mechanism. This will prevent more than one NCMP instance from reading, updating or deleting data related to that cmHandle.