Aws v4 provider syntax upgrade and automating the imports

Terraform Providers AWS
1

We use terraform quite extensively and we are currently on Terraform v1.1.9 and use the AWS provider v3.75.1.

We want to upgrade our syntax to be forward compatible with v4 of the aws provider but the sheer amount of terraform import commands we would have to run is very impractical.

What is the strategy that others have used?

I’m considering to setup a wrapper to automatically run the appropriate import calls for us.
Some options I have in mind are, after calling init:

  • read the existing state file, find deprecated resources and ‘import’ them. That’s a little bit blind as it ignores if the code has been refactored yet, but would apply the import only once.
  • get the parsable output of plan to detect removed resources. This is more aware of the refactoring but could be more difficult to parse.
  • use a combination of both, it is possible that some deprecated resources/attributes will not show in the output of plan.

I’m working with the upgrade guide, but the fact that we have to manually import/migrate the resources on top of refactoring is problematic. In our case we have dozens of test environments which means that hundreds if not thousands of import commands would be required, so we need an automated way to address that.

Once we address all syntax warnings and have all the resources imported we will then upgrade the aws provider to v4.

I would imagine that v3.75 of the provider could be extended to automatically detect that the resource was ‘migrated’ and perform the import automatically but that was not done.

How are others handling this migration?

2

I found this discussion and comment:

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.

So it seems that as long as we do a 1 to 1 conversion, everything should work as expected. So in practice the workflow should be:

  • stop updating your S3 bucket settings
  • upgrade to the latest v3 provider
  • run a plan and apply with your latest terraform files
  • address all the warnings by upgrading to the new s3 resources
  • run plan and apply again
  • upgrade to v4
  • start making changes again