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

Upcoming Changes in Version 4.0 of the AWS Provider #20433

Closed
anGie44 opened this issue Aug 3, 2021 · 9 comments
Closed

Upcoming Changes in Version 4.0 of the AWS Provider #20433

anGie44 opened this issue Aug 3, 2021 · 9 comments
Labels
breaking-change Introduces a breaking change in current functionality; usually deferred to the next major release. enhancement Requests to existing resources that expand the functionality or scope. provider Pertains to the provider itself, rather than any interaction with AWS. service/s3 Issues and PRs that pertain to the s3 service.
Milestone

Comments

@anGie44
Copy link
Contributor

anGie44 commented Aug 3, 2021

In the time since the last major provider release in July of 2020, we have been listening closely to the community's feedback. This major release primarily brings more flexibility and control over configuration settings for an S3 bucket resource (aws_s3_bucket) while standardizing practitioner expectations when using existing resources in the provider with Terraform 0.12+.

Summary

A major release is our opportunity to make breaking changes in a scheduled and publicized manner in an attempt to avoid unnecessary churn for our users. We attempt to limit major releases to a once-yearly schedule. Version v3.0 of the AWS provider was released in July of 2020.

Along with larger changes in behavior detailed below this release will also remove attributes that have been marked as deprecated. Typically these have been marked as such due to changes in the upstream API, or in some cases that the use of the attribute causes confusion.

Refactor the aws_s3_bucket resource

To help distribute management of S3 bucket settings as originally presented in #4418, the focus of this major milestone will be to deprecate (for the purpose of this release, this equates to marking previously configurable arguments as read-only /Computed and with a Deprecated message ) at least the following arguments (subject to change): lifecycle_rule, logging, versioning, replication_configuration, server_side_encryption_configuration. Independent resources for these arguments will include:

  • aws_s3_bucket_lifecycle_configuration
  • aws_s3_bucket_logging
  • aws_s3_bucket_versioning
  • aws_s3_bucket_replication_configuration
  • aws_s3_bucket_server_side_encryption_configuration

Data retention and security considerations are paramount when considering any form of alterations to the aws_s3_bucket resource, therefore upgrade documentation will be made readily available with the appropriate path to adoption of v4.0.0 of the provider.

Adoption of AWS Go SDK V2

While the AWS SDK for Go v2 does not enable additional functionality for managing AWS resources, it does enable support for authenticating with AWS Single Sign-On (AWS SSO) credentials. Since we prefer to make changes to authentication at major version releases, at a minimum, the version of aws-sdk-go-base used in the AWS Provider will be updated to use AWS SDK for Go v2.

Implement Full Resource Lifecycle for Default resources

Default resources, namely aws_default_subnet and aws_default_vpc, previously could only be read and updated. However, recent service changes now enable users to create and delete these resources such that within the provider, corresponding API methods can be utilized to fully implement the Create and Delete resource CRUD operations.

Remove Zero Values from Attribute Validations

As the provider only supports Terraform 0.12 and above, this workaround previously used by 0.11 users should be removed as supported terraform versions include the concept of null in place of zero-values for TypeString and TypeInt values.

Ensure All Plural Data Sources Return Zero Results

For consistency, all Terraform AWS Provider plural data sources that are expected to return an array of results should return an empty list if zero results are found, enabling practitioners to create dynamic implementations based on these results without encountering an error in their workflows.

Follow our Progress

The full contents of the major release and progress towards it can be viewed in the v4.0.0 milestone

Upgrading

As a major version contains breaking changes, it is considered best practice to pin a provider version to avoid bringing in potentially breaking changes automatically. To remain on v3.* versions of the provider until such time that you are able to accommodate those changes, either pin to any v3.* version:

terraform {
  required_providers {
    aws = {
      version = "~> 3.0"
    }
  }
}

Or a specific version:

terraform {
  required_providers {
    aws = {
      version = "3.52.0"
    }
  }
}

Full documentation on how to manage versions of a provider can be found on the Terraform Website.

Your usage patterns will dictate how much effort upgrading to v4.0 will take. We document each breaking change in our upgrade guide which will describe what changes are necessary to existing resources to preserve behavior. The upgrade guide will be available on the day of the release on the Terraform Website.

@grimm26
Copy link
Contributor

grimm26 commented Oct 5, 2021

a suggestion for upcoming aws_s3_bucket_versioning: #12354 (comment)

@sinisterstumble
Copy link

@anGie44 one more suggestion for IPv4 Prefixes and IPv6 Prefixes support for aws_launch_template resource's network_interfaces block. It is listed in the user guide and available in the console.

@anGie44
Copy link
Contributor Author

anGie44 commented Feb 10, 2022

All items complete and will release this afternoon (EST) with v4.0 of the provider.

@anGie44 anGie44 closed this as completed Feb 10, 2022
@github-actions
Copy link

This functionality has been released in v4.0.0 of the Terraform AWS Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

@joe-a-t
Copy link

joe-a-t commented Feb 10, 2022

Opened #23106 per the instructions but wanted to urgently flag this to @anGie44 and link the new issue here

@DanDilag
Copy link

For upgrading to Version 4 do we really need to do this below on the impacted resources?
"It is then recommended running terraform import on each new resource to prevent data loss, "

If we are running a automated deployment this is not possible to run as we are IaC on our deployment with no user execution with terraform commands.

@FernandoMiguel
Copy link
Contributor

For upgrading to Version 4 do we really need to do this below on the impacted resources?
"It is then recommended running terraform import on each new resource to prevent data loss, "

If we are running a automated deployment this is not possible to run as we are IaC on our deployment with no user execution with terraform commands.

Depends on the resource.
You can also use custom ci workflows that do the import for you, but all this sucks big time.

@anGie44
Copy link
Contributor Author

anGie44 commented Apr 14, 2022

Hey all, please note that the changes in the description related to the S3 bucket (aw_s3_bucket resource) are now no longer applicable to all 4.x versions of the AWS provider.

v4.0.0 through v4.8.0 contain the refactored aws_s3_bucket resource such that commonly used parameters like lifecycle_rule, replication_configuration etc are not configurable and errors will occur when upgrading. Please refer to https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-4-upgrade#s3-bucket-refactor for more info.

v4.9.0 and thereafter reverts those changes (per #23106)such that the aws_s3_bucket resource operates in almost the same way as that of previous versions prior to the 4.0 major release, with the exception that Terraform will only perform drift detection on parameters like lifecycle_rule, replication_configuration, etc if they are in fact configured. Please refer to https://registry.terraform.io/providers/hashicorp/aws/latest/docs/guides/version-4-upgrade#changes-to-s3-bucket-drift-detection for more info.

@github-actions
Copy link

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 15, 2022
@breathingdust breathingdust unpinned this issue Jul 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking-change Introduces a breaking change in current functionality; usually deferred to the next major release. enhancement Requests to existing resources that expand the functionality or scope. provider Pertains to the provider itself, rather than any interaction with AWS. service/s3 Issues and PRs that pertain to the s3 service.
Projects
None yet
Development

No branches or pull requests

6 participants