🚀 Enhancements
notes
- Terraform minimum version is now 1.1.0
- AWS provider minimum version is now 4.9.0
This PR contains the following updates:
Package | Type | Update | Change |
---|---|---|---|
cloudposse/s3-log-storage/aws (source) | module | major | 0.26.0 -> 1.1.0
|
Release Notes
cloudposse/terraform-aws-s3-log-storage
v1.1.0
Compare Source
Adding "object_lock_configuration" variable which is used in module "cloudposse/s3-bucket/aws"
Must be able to use the Object Lock option for S3 in this module
Adding "object_lock_configuration" variable @ramses999 (#84)
what
why
references
v1.0.0
Important Notes
- Terraform version 1.3.0 and Terraform AWS version 4.9.0 or later are required
- The new
bucket_key_enabled
flag defaults tofalse
for backward compatibility. At one point we recommend setting it to true for significant savings on KMS usage, but since bucket keys are only reused within a user session, it is not clear if it provides any savings at all. See AWS docs for more information. - The new
lifecycle_configuration_rules
input replaces the now deprecated individual inputs for individual settings of a single lifecycle rule. See the terraform-aws-s3-bucket documentation for details on how to specify lifecycles usinglifecycle_configuration_rules
. This mechanism is much more flexible and closely follows the Terraformaws_s3_bucket_lifecycle_configuration
resource. - The new
source_policy_documents
input replaces the now deprecatedpolicy
input to match changes to theaws_iam_policy_document
resource - You can now select default values for (non-deprecated) inputs by setting them to
null
- With Terraform 1.3 the manual interventions documented for upgrading to this module's versions 0.27.0 and 0.28.0 are no longer needed. You can safely upgrade from any earlier version to this one (although we always recommend leaving
force_destroy
at its default value offalse
, and if you have it set totrue
but want extra safety against the S3 bucket being destroyed, set it tofalse
before upgrading). - The
force_destroy_enabled
flag introduced in v0.27.0 has been removed - In version 0.28.0, old lifecycle rule variables were deprecated and the new
lifecycle_configuration_rules
input was introduced. In that version, you would continue to get the old default lifecycle rule even if you supplied new rules vialifecycle_configuration_rules
. Now, the default behavior is to ignore all the deprecated lifecycle inputs when thelifecycle_configuration_rules
input is not empty, unless you explicitly setlifecycle_rule_enabled
to true.
Enhancements
Automate upgrade using `moved` blocks @Nuru (#81)
what
- Automate the upgrade process from v0.26.0 or earlier by using
moved
block functionality introduced in Terraform 1.3.0 - Add
nullable = false
for module input variables which have a default value and where null is not a sensible/handled value for the variable.
why
- Safely upgrade without loss of data or manual intervention
- Allow users to select default values by setting inputs to
null
, closes #63
v0.28.3
: Not recommended, use v0.26.0 or v1.x instead
Update: This version no longer recommended
With the release of version 1.0.0 of this module, use of this version is no longer recommended. When you are able to use Terraform v1.3.0 or later and Terraform AWS provider v4.9.0 or later, upgrade directly to v1.0.0 or later of this module.
🤖 Automatic Updates
Update Terraform cloudposse/s3-bucket/aws to v3 @renovate (#78)
This PR contains the following updates:
Package | Type | Update | Change |
---|---|---|---|
cloudposse/s3-bucket/aws (source) | module | major | 2.0.1 -> 3.0.0
|
v0.28.2
: Action required if updating from prior to v0.28.0
Update: This version no longer recommended
With the release of version 1.0.0 of this module, use of this version is no longer recommended. When you are able to use Terraform v1.3.0 or later and Terraform AWS provider v4.9.0 or later, upgrade directly to v1.0.0 or later of this module.
v0.28.0 introduced breaking changes with high risk of permanent data loss. See release notes there. This is only a safe upgrade if upgrading from v0.28.0.
We will convert to semantic versioning (incrementing the major version number for breaking changes), but having missed the opportunity to do that for earlier versions of this module, we are waiting for the next major change, expected to be soon after Terraform v1.3 is released.
🤖 Automatic Updates
Update Terraform cloudposse/s3-bucket/aws to v2.0.1 @renovate (#76)
This PR contains the following updates:
Package | Type | Update | Change |
---|---|---|---|
cloudposse/s3-bucket/aws (source) | module | patch | 2.0.0 -> 2.0.1
|
v0.28.1
: accidental release, do not use
v0.28.0 introduced breaking changes with high risk of permanent data loss. See release notes there. This is only a safe upgrade if upgrading from v0.28.0.
We will convert to semantic versioning (incrementing the major version number for breaking changes), but having missed the opportunity to do that for earlier versions of this module, we are waiting for the next major change, expected to be soon after Terraform v1.3 is released.
Change all references to git.io->cloudposse.tools update @dylanbannon (#73)
what and why
git.io/build-harness
into cloudposse.tools/build-harness
, since git.io
redirects will stop working on April 29th, 2022.
References
🤖 Automatic Updates
Update Terraform cloudposse/s3-bucket/aws to v2 @renovate (#72)
This PR contains the following updates:
Package | Type | Update | Change |
---|---|---|---|
cloudposse/s3-bucket/aws (source) | module | major | 0.49.0 -> 2.0.3
|
v0.28.0
: (Action Needed) Support AWS v4 provider
WARNING, DATA LOSS LIKELY if you do not follow upgrade instructions:
- Upgrade instructions: v0.27.0 to v0.28.0
- Upgrade instructions: versions prior to v0.27.0 to v0.27.0
🚀 Enhancements
Support AWS v4 provider @Nuru (#71)
what
- Migrate to AWS v4 Terraform provider
- Add features
- Allow full S3 storage lifecycle configuration
- Allow multiple bucket policy documents
- Allow specifying the bucket name directly, rather than requiring it to be generated by
null-label
- Allow specifying S3 object ownership
- Allow enabling S3 bucket keys for encryption
- Deprecate variable by variable specification of a single storage lifecycle rule
- Add extra safety measure
force_destroy_enabled
why
- AWS v4 broke this module
- Feature parity
- Replaced with more power and more flexible input
- Reduce the chance that automated upgrades will cause data loss
references
- Upgrade instructions: v0.27.0 to v0.28.0
- Upgrade instructions: versions prior to v0.27.0 to v0.27.0
v0.27.0
: (WARNING: Potential Data Loss) Prepare for AWS provider v4
Update: This version no longer recommended
With the release of version 1.0.0 of this module, use of this version is no longer recommended. When you are able to use Terraform v1.3.0 or later and Terraform AWS provider v4.9.0 or later, upgrade directly to v1.0.0 or later of this module.
Warning: Potential total data loss
This release is a refactoring in preparation for supporting Terraform AWS Provider v4. One feature was removed, but otherwise there are no changes to inputs or behavior. However, the Terraform "addresses" of resources have changed, so you are need to run several terraform state mv
commands.
Warning: failure to run the required terraform state mv
commands will cause Terraform to delete your existing S3 bucket and create a new one, deleting all the data stored in the bucket in the process.
Details on how to safely upgrade are in this repository's Wiki here
Support for "MFA delete" removed
In #54 a contributor added support for MFA delete via the versioning_mfa_delete_enabled
. In AWS provider version 3.x this argument was documented with the caveat
This cannot be used to toggle this setting but is available to allow managed buckets to reflect the state in AWS.
With AWS provider version 4.0, this argument now does toggle the setting. Unfortunately, that adds the requirement then when it is enabled, you must supply a current MFA token every time you run terraform apply
. That is not compatible with automation, and therefore we have no intention to support it and have removed the versioning_mfa_delete_enabled
input.
🚀 Enhancements
Refactor to use s3-bucket module, update in general @Nuru (#66)
what
- Refactor to use terraform-aws-s3-bucket
- Remove support for
mfa_delete
- Pin AWS provider
< 4.0
and disable Renovate bot, closes #64 - General updates
why
- Simplify maintenance and standardize on single S3 bucket module, in preparation for upgrade to Terraform AWS provider v4
- With Terraform AWS provider v4, having
mfa_delete
enabled requires entering an MFA token for every Terraform operation, which is incompatible with automation. Users requiringmfa_delete
should either not use Terraform or create their own fork. - Current module does not work with AWS v4, but Renovate would try to update it anyway
- Stay current with boilerplate and management tools
notes
This is the first of 2 upgrade releases to get this module to support Terraform AWS Provider v4. We are breaking it into 2 releases so that users have the option of upgrading step-by-step rather than all at once. Upgrade instructions are here.
Cleanups and safety checks for upgrade @Nuru (#70)
what
- Add warning to README and error when
force_destroy
istrue
- Maintain rule name for lifecycle rule
- Disable Renovate bot
why
- If
force_destroy
istrue
then an automated, unattended process could cause the S3 bucket to be deleted and all data in it irretrievably lost - Remove an unwanted and unneeded source of changes created by upgrading
- This version should not be updated, it is pinned for compability
references
Closes Renovate PRs: