search

mweagle / Sparta

go microservices, powered by AWS Lambda
https://gosparta.io
MIT License
717 stars 48 forks source link

Document "Bucket should have ObjectExpiration lifecycle enabled" #32

Closed jbrook closed 7 years ago

jbrook commented 7 years ago

Hello, I am back to working with Sparta after quite a long break and I think it would be a good idea to document the lifecycle policy rule that should be associated with the S3 bucket. What is a sensible expiration policy? Should the contents of the bucket be permanently deleted? Should that happen almost immediately after the provisioning run?

mjuarez commented 7 years ago

Thanks for this tip. Just ran into this issue and didn't realize the bucket needed this.

mweagle commented 7 years ago

Right now the object expiration policy check is only a warning. It's also pretty opinionated about how to manage AWS resources and overlaps with the object versioning policy that's needed for CodePipeline deploys. What are your thoughts on removing the check entirely?

mjuarez commented 7 years ago

Agreed the policy check would be valuable to have, as long as it's stated that it's needed with an S3 bucket policy. As a separate issue, I came across this requirements as I kept getting permissions errors attempting to fetch this policy (and subsequently realizing the s3:// scheme wasn't necessary when defining buckets).

mweagle commented 7 years ago

This behavior will change with 0.10.0 in order to support version aware buckets & CodePipeline. If a version policy enabled bucket is detected, Sparta will use stable S3 object keys. Otherwise, the existing behavior will continue and random object keys will be used. Given this change, I've removed the warning for the upcoming release.

mweagle commented 7 years ago

Obsoleted by https://github.com/mweagle/Sparta/releases/tag/0.10.0 - closing.