-
Notifications
You must be signed in to change notification settings - Fork 9
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
Support optional access logs #85
Conversation
Provides a way to disable logs. Logging is enabled by default.
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.
I just realized ... do you really want to disable logs??? I think that's a weird pattern to put in our module.
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.
We talked... I agree this is relatively harmless since our default will still be to have logs. This will give folks that consume this more options.
prefix = "alb/${var.name}-${var.environment}" | ||
dynamic "access_logs" { | ||
# Skips creating the block if logs_s3_bucket is empty string | ||
for_each = var.logs_s3_bucket == "" ? [] : ["create block"] |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
940fddc
to
ed215f5
Compare
@LinuxBozo @dynamike @eeeady I believe this is ready for a real review now. |
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.
Playing around with this locally as @LinuxBozo has so amazingly commented on in the test code, I'm able to reproduce this same bug locally. It only happens when you spin up the logs module and this module from scratch. A second apply passes. Running this problem without logging, like @brainsik, doesn't trigger the bug.
The bit that I don't understand is it doesn't appear to be a problem with the https://github.com/trussworks/terraform-aws-s3-private-bucket module, which has he same dynamic logic being used here.
My only request is can we add a Note to the README highlighting this bug, it's a pretty painful one for those using the module with logging for the first time.
|
||
This is a bug in the provider, which should be reported in the provider's own | ||
issue tracker. | ||
https://github.com/terraform-providers/terraform-provider-aws/issues/10297 |
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.
This is another bug report specific to AWS access logs and ALBs
hashicorp/terraform-provider-aws#16674
@brainsik how we hanging on this? |
Woot! The dynamic block planning problem got fixed in Terraform v0.15.2: I'm going to open a new PR with my changes. Apparently the change from |
This came up while I was drafting what a Hello, World project might look like. I don't want the student to have to create an S3 bucket + policy just to bring up an ALB. This felt like a simple change that doesn't impact the default of logging.