-
Notifications
You must be signed in to change notification settings - Fork 4k
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
fix(s3): setting autoDeleteObjects
to false
empties the bucket
#16756
Conversation
This was caused by the Custom Resource--which had previously been deployed when `autoDeleteObjects: true`--being removed when `autoDeleteObjects` is flipped off again. The custom resource would indiscriminately empty the bucket as it was being deleted. Fix by having the custom resource inspect the ongoing CloudFormation deployment: if the bucket would not be deleted as part of the ongoing deployment, also do not empty it. Fixes #16603.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice fix 🚀
packages/@aws-cdk/aws-s3/lib/auto-delete-objects-handler/index.ts
Outdated
Show resolved
Hide resolved
Looks like CI found an integration test that needs an update: |
Co-authored-by: Ryan Parker <ryan.parker3@outlook.com>
…nto huijbers/fix-s3-autodelete
@rix0rrr @ryparker FWIW, as a workaround, we were investigating using CDK metadata on the S3 bucket as a means of telling the lambda whether it should actually clear the bucket or not. (The metadata would be set when |
const destinationTemplateResponse = await cfn.getTemplate({ StackName: stackId, TemplateStage: 'Processed' }).promise(); | ||
let template; | ||
try { | ||
template = yaml.parse(destinationTemplateResponse.TemplateBody ?? '{}', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you describe the changeset here instead of analyzing the template then you don't need the yaml
dependency (and the script to include it in the handler). Better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe. It artificially limits the template's use to cases where we deploy using change sets. Granted, the CDK always does that, but I hate unnecessarily limiting ourselves in that way.
tgt=lib/auto-delete-objects-handler/node_modules/yaml | ||
if [[ ! -d $tgt ]]; then | ||
mkdir -p $tgt | ||
cp -R node_modules/yaml/ $tgt/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what if yaml
gets updated and comes with dependencies? (tests will continue to pass)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rix0rrr Have you considered coupling the custom resource with the bucket, instead of the autoDeleteObjects
property?
I.e the CR will always exist, and the lambda will either no-op if autoDeleteObjects
is false
(or undefined
), or will delete otherwise.
We have considered it. It means that every single one of the 1243891 templates out there that contains an S3 bucket will automatically gain 3 more resources:
And so be "polluted", not to mention the diff we'd be introducing to all customers everywhere. I don't think it would be looked upon graciously |
You know what -- I rejected that initially because of assumptions I made on the CFN lifecycle. Specifically: I thought the following use case would be broken:
My assumption was that the rollback would happen in reverse topological order, and so the CR deletion would happen before the untagging:
However, after documenting the lifecycle, I think the order would actually be:
In which case the tag-based approach is actually completely valid, and requires a smaller code change. I think I will pivot to that. Thanks for reminding me! |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
@@ -0,0 +1,7 @@ | |||
#!/bin/bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this file?
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
* '15588' of https://github.com/xykkong/aws-cdk: (47 commits) chore: rollback `GenericSSMParameterImage` deprecation (backport aws#16798) (aws#16800) chore(deps): bump actions/setup-node from 2.4.0 to 2.4.1 (aws#16778) Update CHANGELOG.md chore(release): 1.126.0 feat(assertions): matcher support for `templateMatches()` API (aws#16789) feat(stepfunctions-tasks): add step concurrency level to EmrCreateCluster (aws#15242) docs(s3): correct heading levels Object Ownership / Bucket deletion (aws#16790) chore(individual-pkg-gen): fix bug in setting alpha package visibility (aws#16787) fix(s3): setting `autoDeleteObjects` to `false` empties the bucket (aws#16756) fix(iam): `User.fromUserArn` does not work for ARNs that include a path (aws#16269) fix(cli): progress bar overshoots count by 1 for stack updates (aws#16168) fix(config): add SourceAccount condition to Lambda permission (aws#16617) docs(events): add a note about not using `EventPattern` with `CfnRule` (aws#16715) docs(core): fix reference to nonexistant enum value (aws#16716) chore(s3-deployments): update python version on BucketDeployment handler (aws#16771) chore: set response-requested length to 2 and closing-soon to 5 (aws#16763) fix(revert): "fix: CDK does not honor NO_PROXY settings (aws#16751)" (aws#16761) docs(GitHub issue templates): Upgrade to GitHub Issues v2 (aws#16592) chore: reset jsii-rosetta worker count to default (aws#16755) fix: CDK does not honor NO_PROXY settings (aws#16751) ...
…16756) This was caused by the Custom Resource--which had previously been deployed when `autoDeleteObjects: true`--being removed when `autoDeleteObjects` is flipped off again. The custom resource would indiscriminately empty the bucket as it was being deleted. Fix by tagging the bucket to confirm that it needs to be emptied. If any deployment removes the CR but keeps the bucket, the ordering of CloudFormation updates will make sure that the untagging happens before the CR gets activated, thereby saving the bucket contents. Fixes #16603. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…ws#16756) This was caused by the Custom Resource--which had previously been deployed when `autoDeleteObjects: true`--being removed when `autoDeleteObjects` is flipped off again. The custom resource would indiscriminately empty the bucket as it was being deleted. Fix by tagging the bucket to confirm that it needs to be emptied. If any deployment removes the CR but keeps the bucket, the ordering of CloudFormation updates will make sure that the untagging happens before the CR gets activated, thereby saving the bucket contents. Fixes aws#16603. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The AutoDeleteObjects Custom Resource should pass when the bucket doesn't exist. With #16756 we introduced a safety check to only delete buckets that are marked for object-deletion. This check would unintentionally bypass the special case to mark the CR deletion as successful when the bucket doesn't exist. Additionally, with the upgrade to SDK v3 we need to change the check from `error.code` to check for the actual error instance. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
The AutoDeleteObjects Custom Resource should pass when the bucket doesn't exist. With aws#16756 we introduced a safety check to only delete buckets that are marked for object-deletion. This check would unintentionally bypass the special case to mark the CR deletion as successful when the bucket doesn't exist. Additionally, with the upgrade to SDK v3 we need to change the check from `error.code` to check for the actual error instance. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This was caused by the Custom Resource--which had previously been
deployed when
autoDeleteObjects: true
--being removed whenautoDeleteObjects
is flipped off again. The custom resource wouldindiscriminately empty the bucket as it was being deleted.
Fix by tagging the bucket to confirm that it needs to be emptied. If
any deployment removes the CR but keeps the bucket, the ordering of
CloudFormation updates will make sure that the untagging happens before
the CR gets activated, thereby saving the bucket contents.
Fixes #16603.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license