#terraform-aws-modules (2023-05)
Terraform Modules
Discussions related to https://github.com/terraform-aws-modules
Archive: https://archive.sweetops.com/terraform-aws-modules/
2023-05-02

Hello team, the error in the aws-flow-logs is the pending PR open at here https://github.com/cloudposse/terraform-aws-vpc-flow-logs-s3-bucket/pull/52.
Can someone from @cloudposse-team check, rebase and approve that s3-logs version upgrade? Same for the
• https://github.com/cloudposse/terraform-aws-s3-bucket
• https://github.com/cloudposse/terraform-aws-cloudfront-s3-cdn Root cause: old s3-logs dependencies to version 0.26.0 in root modules. Upgrade to 1.0.0 minimum is required. Prefered 1.1.0

@José Thank you for this PR.
The recent changes to the S3 resource in the AWS provider have made me question the wisdom of continuing to provide modules such as vpc-flow-logs-s3-bucket
. How would you feel if we removed the ability of that module to create and S3 bucket and required you to make the S3 bucket outside of it (e.g. via s3-log-storage
) and pass in the bucket ARN?

Great. Honestly I had no idea such s3-logs were created until they start failing. Considering that an terraform-aws-s3-bucket already exists and does a perfect job.
Too much redundancy or hidden dependancies, with ARN is simpler an cleaner. Less modules to maintain. Also gives user control to update their own S3 versions.
And what about the other modules which also have this s3-logs dependency like s3-cdn?
Terraform module that creates an S3 bucket with an optional IAM user for external CI/CD systems

We have limited resources and primarily update our open source modules in response to (paying) customer needs. That said, we consider the S3 failures significant, and will prioritize fixing them.
Our general plan is to remove the creation of S3 buckets from most modules and, where modules currently create S3 buckets, accept an S3 bucket ARN instead. We will probably keep s3-log-storage
and s3-website
as well as s3-bucket
but I don’t know what else.

Totally understandable. I would contribute more but I don’t know how to gain access to PR or so.
I have not found any other way to deploy flow_logs in a iso/hipaa/soc2 compliant environment. So for me, is mandatory to use this type of components.

This is not the first time I ask about how to contribute to the project, in the past with some RDS missing cw alarms. Anyway I managed to handle this s3 issue internally for me so far. Waiting for the official version when it comes.

@José You can contribute to the projects by making a pull request. Step-by-step instructions are here among other places.
Note that we are way behind in reviewing pull requests. It may be weeks or months before we get to review it. However, if it solves an urgent need or is very small, you can ask for an expedited review by posting the PR in this channel and tagging the team, as you did at the start of this thread.

Ohh man, thanks, that’s useful.

Modules terraform-aws-s3-bucket and terraform-aws-s3-log-storage have been updated to work with the new AWS S3 defaults. Other modules dependent on them should be updated soon, but if you find one not automatically updated (either no PR or the PR was not auto-merged) and you are waiting on it, ping @cloudposse-team
in this channel with a request to update the module you need.

I’m working on some upgrades to terraform-aws-vpc-flow-logs-s3-bucket
so it may take a couple of days before that is updated and released.

Updates available for review at vpc-flow-logs-s3-bucket PR 54.
what && why
• Update s3-log-storage
module to current 1.2.0. Fixes #53
• Add bucket_name
input and validation. Resolves #48
• Add object_lock_configuration
to keep in sync with upstream modules
• Add new lifecycle_configuration_rules
input and deprecate old individual settings to provide more flexibility and keep in sync with upstream modules
• Update framework workflows and test rigs
• Require Terraform version >= 1.3.0
references
• Supersedes and closes #49 • Supersedes and closes #51 • Supersedes and closes #52
