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.

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

feat: Add support for log bucket configuration #117

Merged

Conversation

matty-rose
Copy link
Contributor

Fixes #88

@comment-bot-dev
Copy link

comment-bot-dev commented May 27, 2021

Thanks for the PR! 🚀
✅ Lint checks have passed.

for_each = var.logging == null ? [] : [var.logging]
content {
log_bucket = var.logging.log_bucket
log_object_prefix = var.logging.log_object_prefix == "" ? var.name : var.logging.log_object_prefix
Copy link
Contributor

Choose a reason for hiding this comment

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

We should use this same logic for the top-level module as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd prefer to keep the top-level module logic the same, as I believe it aligns with the raw bucket resource inputs better. For example this is a valid value for the logging variable in the top-level module:

{
  first = {
    log_bucket = "test-bucket"
  }
  second = {
    log_bucket = "test-bucket"
    log_object_prefix = "test-prefix"
  }
}

and in this case, GCS itself handles making the prefix the same as the bucket name for first.
The only reason I implemented the ternary logic in the simple_bucket module is that I set the type of the input variable to be an object with two strings, and the optional constraint is currently experimental in terraform 0.14. This means that the following is NOT a valid value for logging in the simple_bucket module, and so to obtain the default GCS behaviour I implemented the bucket name/prefix logic manually:

{
  log_bucket = "test-bucket"
}

There are two solutions that I'd choose over re-implementing the logic in the root module:

  1. Change the type of the logging variable in the simple_bucket module to any and document the input format better, similar to the nested objects in lifecycle_rules - this would allow passing in the log_object_prefix field to actually be optional
  2. Leave it as-is, and have a small difference in logic between the modules

What are your thoughts @morgante (Also thanks for taking a look at this so quick!)

Copy link
Contributor

Choose a reason for hiding this comment

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

In that case, I'd like to actually update the simple_bucket submodule to accept log_bucket and log_object_prefix as top-level variables. I don't think the layer of indirection in an object is helpful.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

makes sense, have made this change @morgante

@morgante morgante merged commit eca9c57 into terraform-google-modules:master Jun 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Setting up the log bucket.
3 participants