[CONTROLLER-1950] CDS frontend incorrectly handles root overwrite with multiple shards Created: 25/Jun/20  Updated: 26/Jun/20  Resolved: 26/Jun/20

Status: Resolved
Project: controller
Component/s: clustering
Affects Version/s: None
Fix Version/s: Magnesium SR2, Sodium SR4, 2.0.3

Type: Bug Priority: High
Reporter: Tibor Král Assignee: Robert Varga
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to CONTROLLER-1951 Eliminate TransactionContext.executeM... Resolved
relates to CONTROLLER-1913 Add an option to trigger snapshot cre... Resolved
relates to CONTROLLER-1932 Provide support for Root DTCL reactin... Resolved

 Description   

When writing data to path "/" it is written only to default shard without affecting the others.

Picture this:
We want to replicate primary site to secondary. The primary contains data in 3 shards- topology, inventory and default.
Getting this state and writing it to the secondary datastore will write everything only to the default shard (even though there is data which should be written to different shards). 
Furthermore if the secondary datastore contained any data in those other shards, this data won't be overwritten. 

Committing WRITE transaction to the ROOT (path "/") should delete everything and then correctly write the data to the right shards. So that after the write succeeds the datastore only contains the written data.

 Comments   
Comment by Robert Varga [ 25/Jun/20 ]

This is a failure on part of CDS – if there are multiple shards and the write target is YangInstanceIdentifier.empty(), it needs to split the data being written according to the sharding strategy.

This is a counterpart to CONTROLLER-1932 and complements the logic done in the read() path.

Comment by Robert Varga [ 25/Jun/20 ]

This essentially means that neither merge(), write(), nor delete() paths in TransactionProxy do the right thing with respect to module-based shard splitting. Note how the read() path is handled, simply because that is required for NETCONF.

In the modification paths, though:

  • delete() has to issue delete() to all shards
  • merge() need to traverse each data child, lookup the correct shard, create per-shard ContainerNodes for each touched shard and issue merge() to
  • write() is a combination of delete and merge: i.e. create ContainerNodes for all shards and issue write() to all of them (even if the container is empty)

 

Generated at Wed Feb 07 19:56:50 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.