[Feature] support option to create separate logging bucket

[cdaniluk]

Problem
The backend bucket is created as part of the bootstrapping process. Because it is presumed that the AWS account is empty and therefore has no other buckets when bootstrapping, it logs internally. Per #4 this causes self-referential logging loops. That PR introduces support for an external bucket, but we should also support creating a second bucket for logging.

Solution
Support optionally creating a separate bucket solely for tfstate logging.

Other Ideas
It would be nice if we could create the bucket with self logging during bootstrap then switch over to our designated logging bucket on first run. Possibly we could do this by conditionally checking for the existence of a logging bucket and self-logging if not found.

[sblack4]

Maybe we should have a bootstrap-specific module. These guys named their bootstrap module init https://github.com/telia-oss/terraform-aws-terraform-init

[smiller171]

Maybe we should have a bootstrap-specific module. These guys named their bootstrap module init https://github.com/telia-oss/terraform-aws-terraform-init

That's what this repo is...

[mike-rsi]

In my implementation, I actually create the logging bucket in the TF configuration where I'm consuming this module, but outside of the module itself.

Example:

resource "aws_s3_bucket" "logging" {
  bucket = "my-logging-bucket"
  acl    = "log-delivery-write"
}

module "backend" {
  source  = "rhythmictech/backend/aws"
  version = "2.1.0"

  region = "us-east-1"
  bucket = "my-tfstate-bucket"
  table  = "my-tfstate-table"
  logging_target_bucket = aws_s3_bucket.logging.id
  logging_target_prefix = "my-tfstate-bucket/"
}

This seems to follow HashiCorp's advice on how to deal with conditional resources within a module: https://www.terraform.io/docs/modules/composition.html#conditional-creation-of-objects

Note: I do like to aggregate S3 access logs into a common bucket, so this bucket's use case extends outside the scope of this module, which is also why I thought it made sense to define outside of the module. In the same way, it may make sense to treat the KMS key similarly, but the most important thing for me this time around was to prevent the infinite logging loop. 😄

[smiller171]

You make a good point @mike-rsi. It may make sense for us to document this approach rather than building in logic around conditional creation.

[cdaniluk]

The only downside to this is it is yet more resources we are building prior to the state being in S3. But I think as long as it's templated/documented well, that's not a problem.

[smiller171]

Yeah, and I think the justification around logging loops is reason enough to do it, plus using a secondary bucket is still optional