Project

General

Profile

Story #7364

update the sync logic for basic v1-v2 interoperability

Added by Rob Nahf about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
d1_synchronization
Target version:
Start date:
2015-09-22
Due date:
% Done:

100%

Story Points:
Sprint:

Description

Various issue and topics listed, with individual tasks for each to be created:

  • add back the v1 sync logic for updates
  • exclude sending systemMetadataChanged to AuthMN, from processAuthoritativeUpdate
  • add notifyReplicaNodes to processPossibleNewReplica
  • determine if processPossibleNewReplica logic is same for objects under v1 logic as the rest

  • handle syncing the object to the CN if formatId changes from type DATA to type METADATA or RESOURCEMAP

  • take out serialVersion check up-front for objects under v2 logic.

  • revisit VersionMismatch handling


Subtasks

Task #7378: log occasions when an objectFormat is updated from a DATA one to a METADATA or RESOURCE_MAP oneClosedRob Nahf


Related issues

Related to Infrastructure - Task #3787: CN should detect changed sysmeta and resync objects when needed Closed 2013-06-04
Related to Infrastructure - Bug #7371: A systemMetadata update that changes the formatID from DATA to METADATA or RESOURCE_MAP will not upload the object to the CN New 2015-09-21

Associated revisions

Revision 16383
Added by Rob Nahf about 9 years ago

refs: #7364: updated V2TransferObjectTask to handle MN notification properly, added back the v1 update logic for v1-objects.

Revision 16383
Added by Rob Nahf about 9 years ago

refs: #7364: updated V2TransferObjectTask to handle MN notification properly, added back the v1 update logic for v1-objects.

Revision 16416
Added by Rob Nahf about 9 years ago

refs: #7364, #7371. serialVersion handling changed to ignore MN values, but use the one already in the CN version of it, or initialize to one. Now logging changes to formatID that result in a FormatType change.

Revision 16416
Added by Rob Nahf about 9 years ago

refs: #7364, #7371. serialVersion handling changed to ignore MN values, but use the one already in the CN version of it, or initialize to one. Now logging changes to formatID that result in a FormatType change.

History

#1 Updated by Rob Nahf about 9 years ago

  • Description updated (diff)

#2 Updated by Rob Nahf about 9 years ago

  • Description updated (diff)
  • % Done changed from 0 to 30
  • Status changed from New to In Progress

finished dev on:

  • add back the v1 sync logic for updates
  • exclude sending systemMetadataChanged to AuthMN, from processAuthoritativeUpdate
  • add notifyReplicaNodes to processPossibleNewReplica
  • determine if processPossibleNewReplica logic is same for objects under v1 logic as the rest - yes it's the same

#3 Updated by Rob Nahf about 9 years ago

currently, there isn't a satisfactory mechanism to upload a METADATA or RESOURCE_MAP object if the systemMetadata is already synched (happens if the formatID is corrected and the format type changes). cn.create sets the serialVersion to 1, and refreshes the modification date. the d1.create method will fail if the identifier already exists.

More or less, how does the CN storage subsystem tell the difference between a deleted object (where identifier is 'consumed') and one where the object failed to be added?

#4 Updated by Rob Nahf about 9 years ago

  • Related to Task #3787: CN should detect changed sysmeta and resync objects when needed added

#5 Updated by Rob Nahf about 9 years ago

  • Related to Bug #7371: A systemMetadata update that changes the formatID from DATA to METADATA or RESOURCE_MAP will not upload the object to the CN added

#6 Updated by Rob Nahf about 9 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 30 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)