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.

Sign up for GitHub

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

Jump to bottom

Scope trailing delete policy to blobs prefix only #190

Merged
merged 1 commit into from
Oct 28, 2024
Merged

Scope trailing delete policy to blobs prefix only #190

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions terraform/modules/dandiset_bucket/main.tf
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -308,7 +308,7 @@ data "aws_iam_policy_document" "dandiset_bucket_policy" {


# S3 lifecycle policy that permanently deletes objects with delete markers
# after 30 days.
# after 30 days. Note, this only applies to objects with the `blobs/` prefix.
resource "aws_s3_bucket_lifecycle_configuration" "expire_deleted_objects" {
# Must have bucket versioning enabled first
depends_on = [aws_s3_bucket_versioning.dandiset_bucket]
Expand All @@ -320,7 +320,11 @@ resource "aws_s3_bucket_lifecycle_configuration" "expire_deleted_objects" {
# Based on https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-configuration-examples.html#lifecycle-config-conceptual-ex7
rule {
id = "ExpireOldDeleteMarkers"
filter {}
filter {
# We only want to expire objects with the `blobs/` prefix, i.e. Asset Blobs.
# Other objects in this bucket are not subject to this lifecycle policy.
prefix = "blobs/"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could it be multiple? IIRC there was some bug and we were breeding versions for dandiset manifest exports etc. And also then we keep updating manifests for draft version, and all those could be GCed as well. Eg. for 000003 alone for draft version we have over 200 in the history of those keys

(3) dandi@drogon:~/proj/datalad/datalad-deprecated$ datalad ls -aL s3://dandiarchive/dandisets/000003/draft/assets.yaml | grep DeleteMarker | wc -l
[INFO] S3 session: Connecting to the bucket dandiarchive with authentication 
263

so what about trailing delete also for dandisets/?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The asset trailing delete mechanism requires the dandi-archive application itself to put a delete marker on objects that are ready to be garbage collected. For manifest files, garbage collection is presumably more straightforward and can likely be done with just a single s3 bucket lifecycle rule - to keep this PR scoped to its original purpose, I've opened an issue to discuss that further #192.

}

# Expire objects with delete markers after 30 days
noncurrent_version_expiration {
Expand Down