Note: The feature is still in planning phase. The following page will evolve over time. Might add subpages as well.

Decisions Table

Introduction

The CPS Delta feature is proposed as a new feature to the existing functionalities of CPS. The main idea behind it being is to have the ability to find the delta between two configurations stored in CPS DB.

The Delta feature focuses on two main functionalities:

• • Compare the delta data between the configurations stored in two anchors within the same dataspace.
  • Compare the configuration stored under an anchor against an incoming payload.
• The primary focus of the feature is to calculate the difference between the JSON configurations, irrespective of the schema set. 
• So, the feature will technically allow the user to find the delta between two configurations that belong to two different schema sets.
• The calculated differences can then be used to generate a delta report which can be sent over the Kafka Notification Service to the user.

...

• The feature can be developed as a service that works alongside CPS to work alongside CPS core
• We can expose new endpoints for the feature, wherein the new endpoints can:
  • accept two anchor names (irrespective of their schema) and generate a delta report of the JSON data stored in both the anchors.
  • for comparing an anchor to a payload, we can expose a second endpoint that takes one anchor and raw jSON JSON data as input to generate the delta report or the first endpoint can be used to send the JSON as payload
    • in order to to achieve this the second anchor can be defined as an optional parameter in the request
  the
  • .
• the possibility of including the delta feature as a part of existing API's can also be explored. 
• The feature will only support generating the delta for anchors within the same dataspace.

...

• The delta feature can be used to compare the configuration of two nodes on a network over time (for example configuration changes over days). This can then be used.
  • to identify the cause of configuration change
  • and if the configuration change causes any problems, the delta report can help identify the issue.
• A reference configuration can be stored in an anchor, and a copy/snapshot of this reference configuration can then be further modified by other users. Hence the user will always have a reference configuration which they can be sure of is free of any known issues.
  The delta of the reference configuration and modified configuration can then be used to rectify problems with a node configuration.
  
  • If the changes to the configuration lead to any problems, the users can generate the delta to identify the problems and if required the users can fix the issues with configuration changes or rollback the changes to the reference configuration.
• It can even be used to monitor unwanted deviations in some configuration values. 
• Configuration from one node can be used to deploy other nodes. Or as stated above a reference configuration can be used to deploy multiple different nodes.

...

• the feature sounds similar to the functionality for Temporal.
  • but temporal receives the full configuration of the anchor after an update, instead of the delta of two configurations.
  • Update: Temporal has been disabled in CPS

Open Questions

• Can the functionality be expanded to anchors within different dataspaces?

Final Decisions

...

Delta feature for CPS will have 2 APIs:

• First API to generate Delta between 2 anchors. Detailed documentation for first API can be found here.
• Second API to generate delta between an anchor and a JSON payload. Detailed documentation for second API can be found here.
• To work on a notification service to publish the delta generated as Kafka events.
• Delta generated will not be persisted.
• Delta feature will be limited to one dataspace.

References/Future Changes

• CPS-2310: Refactoring of CPS Delta APIs