Project

General

Profile

Story #832

As a CN, a mechanism will need to refresh the entire holdings of a member node

Added by Robert Waltz about 11 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
High
Assignee:
Robert Waltz
Category:
d1_cn_service
Target version:
Start date:
2014-10-02
Due date:
2014-10-02
% Done:

100%

Story Points:
Sprint:

Description

A MN may need to indicate to a coordinating node that its entire collections should be synchronized. Default synchronization of CNs will only took at the time-period since the last synchronization occurred. However, if an event occurs on the MN that inserts records with create dates before the last synchronization period, the collection on the CN may not be complete.

A CN may also take the initiative and run a background process that checks all the objects on a MN and compare them to CN holdings.


Subtasks

Task #709: Update or Delete obsoleted SciMetadata in Solr IndexRejectedRobert Waltz

History

#1 Updated by Robert Waltz about 11 years ago

  • Tracker changed from Task to Story
  • Milestone set to CCI-0.6

#2 Updated by Matthew Jones about 11 years ago

In a production environment, this is a dangerous operation. MNs really shouldn't be able to wholesale replace objects that they've previously registered with new objects that use the same GUIDs, and this would violate GUID contracts and our ability to replicate content effectively. It seems that would be the main purpose of this operation, and therefore is something we probably should not support. What is the use case for a MN to be replacing all of its content (outside of, e.g., warez sites, etc)?

#3 Updated by Robert Waltz over 10 years ago

  • Milestone deleted (CCI-0.6)

#4 Updated by Dave Vieglais over 10 years ago

  • Target version set to Sprint-2011.33-Block.4
  • Position set to 1

#5 Updated by Dave Vieglais over 10 years ago

  • Target version changed from Sprint-2011.33-Block.4 to Sprint-2011.32-Block.4
  • Position set to 1
  • Position deleted (1)

#6 Updated by Dave Vieglais over 10 years ago

  • Position set to 1
  • Target version deleted (Sprint-2011.32-Block.4)
  • Position deleted (28)

#7 Updated by Dave Vieglais over 10 years ago

  • Position set to 3
  • Position deleted (13)

#8 Updated by Dave Vieglais over 10 years ago

  • Position set to 7
  • Position deleted (13)

#9 Updated by Robert Waltz about 10 years ago

  • Subject changed from As a CN, a member node will need a mechanism to refresh entire holdings to As a CN, a mechanism will need to refresh the entire holdings of a member node
  • Milestone set to None

#10 Updated by Dave Vieglais almost 10 years ago

  • Position deleted (84)
  • Position set to 29

#11 Updated by Robert Waltz over 9 years ago

  • Milestone changed from None to CCI-1.1

#12 Updated by Robert Waltz about 9 years ago

  • Milestone changed from CCI-1.1 to CCI-1.2

#13 Updated by Robert Waltz over 7 years ago

  • Milestone changed from CCI-1.2 to None

#14 Updated by Dave Vieglais about 7 years ago

  • Start date set to 2014-10-02
  • Target version set to Maintenance Backlog
  • Due date set to 2014-10-02

#15 Updated by Bruce Wilson about 7 years ago

per discussion 2014-10-02 at AHM: Document this (via ask.dataone.org and operations documentation). The MN should send an email (e.g. to operations@dataone.org). An operations staff person will contact the MN to validate and then manually update the last harvest date. This task is rare enough and potentially expensive enough to execute that it does not need to be automated.

#16 Updated by Dave Vieglais almost 4 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)