Refactor aws s3 bucket to be compatible with Aws provider 4.0 #43
Comments
2 tasks
This was referenced Mar 12, 2022
jim80net
pushed a commit
that referenced
this issue
Mar 14, 2022
closes #43 BREAKING CHANGE: Each of the new aws_s3_bucket_* resources relies on S3 API calls that utilize a PUT action in order to modify the target S3 bucket. Because these API calls adhere to standard HTTP methods for REST APIs, they should handle situations where the target configuration already exists (as noted in the [HTTP RFC](https://datatracker.ietf.org/doc/html/rfc2616#section-9.6)). Given that this is the case, it's not strictly necessary to import any new aws_s3_bucket_* resources that are a one-to-one translation from previous versions of the AWS provider -- on the next terraform apply, they'll attempt the PUT, and update the state with the results as necessary. There is, however, a downside to this approach in that the diff will show each of the new resources as needing to be created.
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
terraform-aws-datadog/logs_monitoring_elb.tf
Line 28 in b0c3afe
terraform-provider-aws 4.0.0 was released, introducing a breaking change to how s3 buckets are defined.
This resource should be refactored to comply with the 4.0 standard. Since doing so breaks compatibility with <4.0.0, this should also increment the major versions and create a new branch.
A migration guide should also be published for users who are on terraform-provider-aws 3.x and desire to upgrade to 4.x
The text was updated successfully, but these errors were encountered: