Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle Moabs that are moved between storage_roots #1139

Open
julianmorley opened this issue Feb 26, 2019 · 7 comments
Open

Handle Moabs that are moved between storage_roots #1139

julianmorley opened this issue Feb 26, 2019 · 7 comments

Comments

@julianmorley
Copy link
Member

julianmorley commented Feb 26, 2019

See current manual fix here:
https://github.com/sul-dlss/preservation_catalog/wiki/A-Moab-Has-Moved

A Moab directory is moved between storage roots.

What currently happens: M2C runs, finds an existing Moab in the 'wrong' storage root, errors out. CM record is not updated. Further processing (new versions) of that Moab stop.

What should happen: M2C runs, finds an existing Moab in the 'wrong' storage root.

  • checks current storage root to see if Moab still lives there as well
    -If yes, error out as before (PresCat doesn't support same Moab in 2 different locations).
    -If no, updates CM to reflect new location, runs CV on the Moab to make sure it transferred OK.
@julianmorley
Copy link
Member Author

julianmorley commented May 5, 2019

This is super annoying. I've got another 42 druids that need manual remediation because of this. Making this high priority because it's relying on my OOB bash scripts to even know that some druids aren't replicating properly. Without those scripts I wouldn't even know this was happening.

@jmartin-sul
Copy link
Member

see also #1185 (which we think usually happens when something is moved, but not completely/correctly)

@justinlittman justinlittman self-assigned this Dec 13, 2019
@justinlittman
Copy link
Contributor

@jmartin-sul @ndushay This refers to the case in which auditing a storage root finds an unexpected moab. Is there also a case in which auditing a moab finds it not at the expected storage root?

@justinlittman
Copy link
Contributor

Ahh, yes ... C2M. Do we need to handle the autofix in both cases (auditing the moabs on disk against the catalog finds the problem, auditing the catalog against the moab on disk finds the problem)?

@justinlittman
Copy link
Contributor

Declaring bankruptcy on this and #1159 as (1) relationship between complete_moab and zipped_moab_versions needs to be considered (viz., what happens to the zipped_moab_versions when a complete_moab is moved or deleted) and (2) how all of this relates to the proposal to run multiple instances of pres cat on multiple storage roots.

@jmartin-sul
Copy link
Member

as part of the migration to Ceph during the summer of 2020, we wrote some helper code to make it easier to move a Moab to a different storage root. we may want to make sure our documentation is up to date on that front, and there may be some polish we could add, but i think this is mostly done? so i think the action for this ticket is now, "what if anything is left?" and if there is remaining work, i'd propose we create new follow on tickets (for documentation or polish as needed)

@ndushay
Copy link
Contributor

ndushay commented Nov 14, 2022

@jmartin-sul It would be great if you would take on what you said above:

  • make sure documentation is up to date for helper code to migrate Moabs to a different root (faster for you to write the missing documentation, or to write tickets?)
  • close this if nothing else comes to mind.

Or put the above in a separate ticket, take the ticket, and close this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants