Use Case 44 - Deprecate a Member Node¶

Goal¶

Remove a Member Node from production, retain access to content (optionally archived).

Summary¶

This use case describes a situation where a Member Node is being taken off line and removed from production. A goal of DataONE is to ensure the content remains accessible, so it is necessary to ensure that the content is replicated before the Member Node is decomissioned and so no longer responsive.

In an ideal situation, the Membe Node is fully functioning and so responsive to the commands necessary to manipulate the content. The alternative, of deprecating a Member Node that is no longer functional is possible, though it depends on whether the content is still accessible.

Actors¶

Content Owner
Member Node
Replica Member Node
Coordinating Node
Coordinating Node administrator

Preconditions¶

Member Node to be decommissioned is synchronized
Content originating on the Member Node is accessible
Replacement Member Node is known

Triggers¶

An administrative decision is made to decommission a Member Node

Post Conditions¶

Content synchronized from the deprecated Member Node is accessible
Authoritative Member Node is changed
Optional: content is archived
Optional: content ownership is changed

$@startuml autonumber "[0] " actor Owner participant "Member Node" as MN participant "Coordinating Node" as CN participant "Replication Node" as RMN actor "CN Administrator" as admin Owner -> MN: listObjects loop for each PID Owner -> CN: getSystemMetadata(PID) activate CN CN -> Owner: systemMetadata deactivate CN Owner -> Owner: edit\nreplication policy Owner -> CN: Use Case 42\nupdate System Metadata CN -> RMN: Use Case 09\nReplicate end admin -> CN: listObjects loop for each PID from MN admin -> CN: verify replication admin -> CN: getSystemMetadata(PID) activate CN CN -> admin: systemMetadata deactivate CN admin -> admin: edit:\nreplica location\nauthoritative MN\n[archive]\n[owner] admin -> CN: Use Case 42\nupdate System Metadata end admin -> CN: unregister MN Owner -> MN: shutdown @enduml$

Figue 1. Process for decomissioning a Member Node that is still functional. First, a content owner updates the replication policy for each object on the MN and ensures that the CN has the updated information (steps 1-5). Next, a CN administrator retrieves a list of objects that need to be managed. For each object, the administrator then ensures that the object has been replicated (8), retrieve the system metadata and edits it (9-11), ensuring that the system metadata properties reflect the new state of the system, then posts the updated system metadata to the CN (12). Once all the content has been updated, the old MN is un-regitered from the Coordinating Nodes. At this point, the Member Node operator can shut down the node.