Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

CDS frontend incorrectly handles root overwrite with multiple shards

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.

Environment

None

Activity

Show:

Robert Varga June 25, 2020 at 1:37 PM

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)

 

Robert Varga June 25, 2020 at 1:13 PM

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 and complements the logic done in the read() path.

Done

Details

Assignee

Reporter

Components

Fix versions

Priority

Created June 25, 2020 at 1:00 PM
Updated February 6, 2025 at 2:13 PM
Resolved June 26, 2020 at 9:22 PM