Task #7773: Test content in PPBio in production - Member Nodes - DataONE Tasks

Task #7773

MNDeployment #3748: PPBIO Member Node

Task #6187: PPBIO: Testing

Task #6244: PPBIO: Transition to production

Test content in PPBio in production

Added by Laura Moyers almost 8 years ago. Updated almost 8 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Mark Servilla

Target version:

Operational

Start date:

2016-05-06

Due date:

% Done:

100%

Story Points:

Sprint:

Description

There is test content in the production PPBio MN. They are re-using their test instance as their production MN, so the test content carried over from stage.

See list of identifiers (attached) for records generated during testing in stage. These records should be archived before announcing PPBio as a production MN.

PPBio prod test records from stage.xlsx - list of identifiers of test content to be archived in production (10.1 KB) Laura Moyers, 2016-05-06 18:06

PPBIO-test.txt (3.98 KB) Mark Servilla, 2016-05-11 22:12

PPBIO-test-archive.txt (31 KB) Mark Servilla, 2016-05-12 14:52

PPBIO-test-delete.txt (64.3 KB) Mark Servilla, 2016-05-12 17:13

History

#1 Updated by Mark Servilla almost 8 years ago

% Done changed from 0 to 30
Status changed from New to In Progress

#2 Updated by Mark Servilla almost 8 years ago

File PPBIO-test.txt added

There are 104 "test" objects that are in urn:node:PPBIO (see attachment) and, through synchronization, in the CN production environment. Because these objects have a replication policy set to , there are replicas at minimum 2 other MNs.

Dave Vieglais has provided the following discussion and removal instructions:

When archiving an object, all replicas will (should, by design) also be archived by the system. Basically, an object is archived on the MN, the CN is notified and the CN then notifies all replicas that the system metadata has changed. It should only be necessary to set the archive flag on the authoritative MN.

The authoritative MN for an object can be determined by examining the system metadata, the “authoritativeMemberNode” contains the node ID.

The originMemberNode field indicates where the content originally came from. In many cases this will be the same as the authoritativeMemberNode.

All replicas of content have the same system metadata, hence they all have the same replication policy. There is no separate replication policy held by replicas.

To resolve this particular situation with PPBio, the process will be something like:

Get a list of test PIDs (origin MN is PPBio and the PID matches a pattern for test identifiers)

For each PID found in #1, verify that it is test content

Set the archive flag for each test PID by calling mn.archive

Verify that the test PIDs no longer appear in searches.

We then need to purge the content using the CN.delete method for each of those PIDs. Technically it is not necessary to do the archive first, but I think in general it is a procedure that should be followed to ensure the content is quickly removed from the search index prior to full deletion.