3.3.4.12. MBR.003.006 Deposit archival confirmation

[Pcolar]

Verify all steps: 1) Deposits should be created (Status “Open”), filled out with content (Status “Open”) and then archived (“Processing” > “Archiving” > “Archived”). 2) User is asked to confirm that everything is uploaded and initiate the process for the permanent deposit of the content in the platform. 3) Content of the deposit is verified (not being able to continue with empty deposits, etc.) and the user is asked for confirmation of the deposit. 4) When accessing them by the URL (from an email message, see MBR.002.000) from the Deposits overview (above), we can see a confirmation about the deposit process, including the following information, and when the user selects “Initiate Permanent Preservation”, the processing phase is initiated. 5) User is transferred to the MBR.003.002 Deposit details view

[Pcolar]

LibNova will not flag the status as "Archived" until content is verified as ingested by USC. This requires checking the USC supplied metadata file, which is produced every 7 days. Review of the changes in status, verification, and timeline is pending.

[oxsdd]

This requires checking the USC supplied metadata file, which is produced every 7 days.

This is not necessarily true, depending upon the definition of "verified as ingested by USC".

For each ingest manifest (.ucm.xml file) submitted by LibNova to the UCM system, it will receive a status file (.ucm.status.xml) when the files in that manifest have been "ingested". Please see the UCM specification.

There are currently two possible criteria for "ingested" w.r.t. the ingest manifest status:

• Files written to HSM cache disk and digest verified;
• Files written to tape at USC.

The first value was requested by Libnova for their testing, and was configured in the test environment. In the production environment, the default value is "files written to tape". Note that this criteria can also be specified on a per-manifest basis, as documented in the ingest manifest XML schema, overriding the default for the ingest folder.

If "verified ingested by USC" is interpreted in other ways, then the ingest manifest status mechanism is not sufficient, and waiting for the particular combination of events to be reflected in the weekly audit CSV will be required. If more responsiveness is desired, then UCM could be enhanced to support additional criteria for determining when a file has been "ingested".

Please see this response to Alberto Carrasco's question, as it explains the various steps in the USC ingest, fixity, and replication processes: https://github.com/oxsdd/ucm-dpn/issues/2#issuecomment-382810684.

@Pcolar I am unable to @mention wmccown at USC in these issues. Is he configured as a collaborator? If not could you please add him so I can keep him in the loop?

[Pcolar]

wmccown added as a collaborator, awaiting his confirmation. Note copied from oxsdd/ucm-dpn#2 (comment):

• Primary Tape Archiving at USC -- In the production environment, you will not receive a .ucm.status.xml file until all files in the manifest -- have one tape copy at the USC tape archive and/or have failed ingest. -- Note that the criteria for an ingest being "complete" is configurable. It can be configured also to -- mean that the file is written to tape archive cache disk, not to tape. In this case, the archiving of the -- file to tape would be indicated by a metadata field.

DPN Note:

• It would be helpful to construct a state diagram of status and verify that against the configuration file.

[Pcolar]

This can be resolved by validation of issue: https://github.com/dpn-admin/EXANode-Acceptance-testing/issues/11

[Pcolar]

Transferred to Issue: https://github.com/dpn-admin/EXANode-Acceptance-testing/issues/11