feat!: enable support for aws provider 4.0+ #49
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jim80net
changed the title
github-actions bot
pushed a commit
that referenced
this pull request
Apr 5, 2022
# [3.0.0](v2.7.0...v3.0.0) (2022-04-05) * feat!: enable support for aws provider 4.0+ (#49) ([5bc98cb](5bc98cb)), closes [#49](#49) ### BREAKING CHANGES * This release drops support for AWS provider <4.0 When updating to this version, the diff will show each of the new resources as needing to be created. However, 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). 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.
|
🎉 This PR is included in version 3.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
github-actions bot
pushed a commit
to YouLend/terraform-aws-datadog
that referenced
this pull request
Nov 8, 2023
# [3.0.0](v2.5.0...v3.0.0) (2023-11-08) ### Bug Fixes * 6764: add eks iam permissions to datadog policy ([215210f](215210f)) * 6764: add the dev datadog role in the sts assume role ([518ccfe](518ccfe)) * 6764: remove aws tag filter for rds ([1981c9e](1981c9e)) * 6764: remove depcreted arguments from s3 ([ece8ee0](ece8ee0)) * 6764: remove dev account from sts ([1b8962d](1b8962d)) * 6764: remove lifecyle rule ([c4415fd](c4415fd)) * 6764: remove rds tag filter ([3edff7e](3edff7e)) * 6764: remove required version in module ([a70a53b](a70a53b)) * 6764: remove sts for usprod and dev ([e4e4280](e4e4280)) * 6764: solve merge conflict ([30b4a41](30b4a41)) * 6764: solve merge conflict2 ([917b3ae](917b3ae)) * 6764: test rds namespace tag filter ([3c96389](3c96389)) * 6764: update the name of elb log bucket ([a1b57aa](a1b57aa)) * 7413: update release tags ([c6d43fa](c6d43fa)) * 7413: update release tags ([17bb1ce](17bb1ce)) * explicitly specify the versions for semantic-release ([scribd#42](https://github.com/YouLend/terraform-aws-datadog/issues/42)) ([09bd8b9](09bd8b9)) * hosted_tags: making host_tags and filter_tags ([9dbf24f](9dbf24f)) * restrict aws provider to <4 for this major branch ([scribd#47](https://github.com/YouLend/terraform-aws-datadog/issues/47)) ([07de45a](07de45a)) * feat!: enable support for aws provider 4.0+ (scribd#49) ([5bc98cb](5bc98cb)), closes [scribd#49](https://github.com/YouLend/terraform-aws-datadog/issues/49) ### Features * (HEAD: adding waf logging in Datadog ([7c96569](7c96569)) * 6764: add cspm_resource_collection_enabled ([e6ce70f](e6ce70f)) * 6764: add cspm_resource_collection_enabled ([02c26a2](02c26a2)) * 6764: add dev and usprod in the sts assume role ([5bdfb8d](5bdfb8d)) * 6764: add lambda forward function ([543caf4](543caf4)) * 6764: add metrics collection and update iam role ([440d86e](440d86e)) * 6764: add rds tag filters ([dbbddc3](dbbddc3)) * 6764: pre-commit ([3b0babe](3b0babe)) * 6764: remove db uat from datadog ([8731628](8731628)) * 6764: remove uat db from monitoring ([e57525e](e57525e)) * 6764: testing aws tag filter ([de928e1](de928e1)) * 6764: testing aws tag filter ([f6fbb9f](f6fbb9f)) * 7413: terraform required version change to 1.1.0 ([1a2379f](1a2379f)) * 7413: upgrade Module DataDog v2.5.0 ([28cd263](28cd263)) * enable support for Datadog provider 3.x ([e42de0e](e42de0e)) * enable support for Terraform 1.1.3 ([scribd#40](https://github.com/YouLend/terraform-aws-datadog/issues/40)) ([51c5279](51c5279)) ### BREAKING CHANGES * This release drops support for AWS provider <4.0 When updating to this version, the diff will show each of the new resources as needing to be created. However, 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). 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should fix #43
BREAKING CHANGE
Based on the below understanding , I think we do not need to do manual import in most of the cases. However we should create a major version though.
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). 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.