Because Tator can support a large number of object storage providers and storage configurations, it is difficult to ensure full support for archive and restore. In addition the best strategy for restoration often varies. For example, if using Amazon S3, there are tradeoffs for cost and restoration speed, as well as duration of restoration. Given this we should delegate storage lifecycle to devops engineers with control over object storage rather than effectively replicating object storage APIs within Tator. This task should result in the following:
Removal of backup buckets - deployment administrators are responsible for implementing bucket replication
Removal of the archive_state and archive_lifecycle parameters in the Media endpoints
Removal of cron jobs related to archive and restore
To indicate archive status on projects where this is part of the media lifecycle, a prerequisite to this issue is #1349. This issue also supersedes #940, #651, #644, and #467.
Because Tator can support a large number of object storage providers and storage configurations, it is difficult to ensure full support for archive and restore. In addition the best strategy for restoration often varies. For example, if using Amazon S3, there are tradeoffs for cost and restoration speed, as well as duration of restoration. Given this we should delegate storage lifecycle to devops engineers with control over object storage rather than effectively replicating object storage APIs within Tator. This task should result in the following:
archive_state
andarchive_lifecycle
parameters in theMedia
endpointsTo indicate archive status on projects where this is part of the media lifecycle, a prerequisite to this issue is #1349. This issue also supersedes #940, #651, #644, and #467.