Project

General

Profile

Story #4463

Incorporate Node Replication Policy into replication processing

Added by Skye Roseboom over 10 years ago. Updated almost 7 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Rob Nahf
Category:
d1_replication
Target version:
CCI-2.4.0
Start date:
2014-09-10
Due date:
% Done:

30%

Story Points:
Sprint:
Infrastructure backlog

Description

Once MN replication policy are available through the Node Repository datasource, replication processing will need to be updated to honor this default replication policy when items without any policy are synchronized to the CN.

This task needs to follow redmine #2192.

Subtasks

Task #6372: rehabilitate ReplicationManager "unit" testsIn ProgressRob Nahf

Task #6373: utilize the new ApacheDS LDAP testing infrastructureClosedRob Nahf

Task #6374: Configure ReplicationManagerTestUnit with AttemptHistoryRepository ClosedRob Nahf

Task #6375: Refactor out dependency on a working CNIn ProgressRob Nahf

Task #6376: test the new strategy against working ReplicationManager testNewRob Nahf

Task #6378: code up the new strategyTestingRob Nahf

Related issues

Related to Infrastructure - Story #2192: Implement NodeReplicationPolicy in Node Registry Service Closed 2014-09-02 2015-01-06
Related to Infrastructure - Story #8639: Replication performance is too slow to service demand New 2018-07-04

History

#1 Updated by Skye Roseboom over 10 years ago

  • Assignee deleted (Robert Waltz)

#2 Updated by Skye Roseboom over 10 years ago

  • Subject changed from Incorporate MN Replication Policy into replication processing to Incorporate Node Replication Policy into replication processing

#3 Updated by Skye Roseboom over 10 years ago

  • translation missing: en.field_remaining_hours set to 0.0
  • Tracker changed from Task to Story
  • Due date set to 2014-04-26

#4 Updated by Rob Nahf about 10 years ago

  • % Done changed from 0 to 20
  • Assignee set to Rob Nahf

implementing in ReplicationManager class in trunk (v2.0).

It would be interesting to create a NodeRegistry query to return the set of possible nodes for a given object, but are probably constrained to use the hazelcast-backed map of Nodes, because that's where we are getting our systemMetadata. so I'll continue to use that structure.

Need to determine if the PreferredMemberNode list is ordered or unordered, and if we need any 'distribution' across preferred nodes.

#5 Updated by Rob Nahf about 10 years ago

  • Status changed from New to In Progress

this became a complicated task, because ReplicationManager tests were commented out (over a year ago), and some v2 changes have been subsequently committed. Will have to rehabilitate the tests before being able to test the new strategy. I'm creating subtasks for these.

#6 Updated by Robert Waltz about 10 years ago

  • Target version changed from 2014.16-Block.2.4 to CCI-1.5.0
  • Due date changed from 2014-09-10 to 2014-09-24

#7 Updated by Robert Waltz about 10 years ago

  • Due date changed from 2014-09-24 to 2014-10-02
  • Target version changed from CCI-1.5.0 to CCI-1.5.1

#8 Updated by Rob Nahf almost 10 years ago

  • Target version changed from CCI-1.5.1 to CCI-2.0.0
  • Due date changed from 2014-10-02 to 2015-01-06

#9 Updated by Rob Nahf over 9 years ago

  • % Done changed from 68 to 30
  • Target version changed from CCI-2.0.0 to CCI-2.1.0

moving out of v2.0 release to v2.1 after review of 2.0.0 backlog at infrastructure meeting.

#10 Updated by Rob Nahf almost 9 years ago

  • Target version changed from CCI-2.1.0 to CCI-2.2.0

#11 Updated by Rob Nahf over 8 years ago

  • Target version changed from CCI-2.2.0 to CCI-2.3.0

#12 Updated by Dave Vieglais over 8 years ago

  • Target version changed from CCI-2.3.0 to CCI-2.4.0

#13 Updated by Dave Vieglais almost 7 years ago

  • Sprint set to Infrastructure backlog

#14 Updated by Dave Vieglais over 6 years ago

  • Related to Story #8639: Replication performance is too slow to service demand added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)