Project

General

Profile

Story #7251

Replication should fulfill policies with no requested number of replicas

Added by Chris Jones over 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
d1_replication
Target version:
Start date:
2015-07-10
Due date:
% Done:

100%

Story Points:
Sprint:

Description

We have seen some cases where ReplicationPolicy.replicationAllowed is set to "true", but there is no ReplicationPolicy.numReplicas attribute. It looks like the ReplicationManager on the Coordinating Nodes is defaulting to zero replicas in this case, rather than a default of say 1, 2, or 3. Fix the ReplicationManager to default to a number greater than zero for objects that state replicationAllowed=true. In the absence of a ReplicationPolicy, still default to zero.

An example of this issue arose with many system metadata documents for TERN objects, such as:

https://cn.dataone.org/cn/v1/meta/aekos.org.au%2Fcollection%2Fnsw.gov.au%2Fnsw_atlas%2Fvis_flora_module%2FNP_WAAL.20150515


Subtasks

Task #7252: Re-replicate content with no numReplicas attributeRejected

Task #7643: Re-replicate content where v1 MNReplication is not available (false or not listed)Closed

Associated revisions

Revision 17560
Added by Rob Nahf almost 9 years ago

refs #7251: found source of NPE and fixed the source node version check.

Revision 17560
Added by Rob Nahf almost 9 years ago

refs #7251: found source of NPE and fixed the source node version check.

Revision 17625
Added by Robert Waltz almost 9 years ago

refs #7251

replicationTestNodeList used for unit testing excluded Read and other APIs from V2 nodes causing ReplicationManagerTestUnit to fail.

Revision 17625
Added by Robert Waltz almost 9 years ago

refs #7251

replicationTestNodeList used for unit testing excluded Read and other APIs from V2 nodes causing ReplicationManagerTestUnit to fail.

History

#1 Updated by Rob Nahf almost 9 years ago

  • Target version changed from CCI-2.1.0 to CCI-2.2.0
  • % Done changed from 0 to 30
  • Milestone set to None
  • Project changed from CN REST to Infrastructure
  • Category changed from d1_replication to d1_replication
  • Status changed from New to In Progress
  • Assignee changed from Chris Jones to Rob Nahf

Replication is failing for this TERN object for different reason: d1_replication is mistakenly checking the registered Node.services for MN_Replication, instead of MN_Read.

checking for registration of the MN_replication service goes way back to 2013, back when we weren't replicating content, so lay dormant.

Although this is a bug, would like to move this to v2.2.0, where the other replication stories are being worked on.

#2 Updated by Rob Nahf almost 9 years ago

  • Status changed from In Progress to Testing
  • Target version changed from CCI-2.2.0 to CCI-2.1.0
  • % Done changed from 30 to 50

moved back to 2.1, because fix is straightforward.

Will need to find places where the replication policy was not fulfilled, in TERN and elsewhere. This happens after the code fix is in place.

#3 Updated by Dave Vieglais over 8 years ago

  • Status changed from Testing to Closed
  • % Done changed from 50 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)