Skip to main content

The post-migration checklist

GET 
/migrate/checklist

Required role: admin. Only an account or token with the admin role can call this operation.

Example request
curl --request GET \
  --header "Authorization: Bearer $HOSERVA_TOKEN" \
  "https://$HOSERVA_HOST:8008/api/v1/migrate/checklist"

Phase D's closing steps as a checklist, each item's state taken from a record where one exists, so it cannot say something was done when it was not. The migration counts as finished exactly when the array record carries the time the point of no return finished (initializeMigrationParity), which is written in the same statement that ends it and by nothing else: finished is true and finishedAt is that time. A migration that is pending, part-way through its point of no return, or was undone has none, and so has an array created by hand or one that finished before this record existed; then finished is false, finishedAt is absent and items is empty: the checklist does not apply. getMigration keeps no "complete" phase.

appdata_cache is done by a succeeded share_relocation job for the appdata share to the cache (startShareRelocation), and not_applicable when the scan read the capture's disk roles and the source had no cache. initial_sync is done by the first succeeded sync that is not a dry run and was created after finishedAt. full_scrub is done by a succeeded scrub with percent 100 and allBlocks true that started after that sync ended, and stays todo until the initial sync is done. A scrub without allBlocks skips blocks synced within the last days, so it checks nothing right after a sync and never counts. notifications is done once an enabled channel's test (sendTestNotification) has succeeded in a later second than the one the channel last changed in; the Unraid notification agents the scan found are named so the user knows what to recreate, and no secret is carried over. schedules is done once the nightly chain's mover, sync and scrub steps are all enabled (updateMaintenanceChainSchedule); it offers the values the scan read from Unraid: its mover schedule as the mover schedule, its parity-check schedule as the scrub schedule (a non-correcting check maps to a scrub that only reports) and its spin-down delay as the default. Unraid's parity is updated as files are written, so there is no Unraid sync schedule to carry over: nothing is offered for sync and the user chooses one.

user_scripts and restore_drill have no record to derive from and are done by acknowledgeMigrationChecklistItem: the first lists the User Scripts the scan found, by name and schedule (a script is never executed or translated); the second shows the latest succeeded fix job that had a path, which an acknowledgement records. Only those two are ever acknowledgeable. The checklist needs no scan: without a report the offers, the agents and the scripts are empty.

Responses​

The checklist.