"Computed attribute cannot be set" for aws_s3_bucket region

Terraform Providers AWS
1

When using terraform validate in a reusable module that uses computed attributes, it marks the attribute as an error with “Computed attribute cannot be set”.

Seeing as terraform validate is documented to be usable for re-usable modules in a CI system, and computed attributes are something re-usable modules are expected to have, it is a bit surprising that computed attributes are marked as errors.

Is this a bug? Is there a workaround for validating re-usable modules that use computed attributes?

2

I can’t quite understand what the error you’re seeing here is coming from Which version of Terraform are you using? Are you able to share a minimal configuration that demonstrates the issue?

3

This example fails validation on 0.13.0

# test-module/main.tf
provider "aws" {
  alias = "alternative_region"
}

data "aws_region" "alt" {
  provider = "aws.alternative_region"
}

resource "aws_s3_bucket" "backup" {
  bucket = "test-${data.aws_region.alt.name}-backup-bucket"
  region = data.aws_region.alt.name
  provider = "aws.alternative_region"
}

$ cd test-module/
$ terraform init

Initializing the backend...

Initializing provider plugins...
- Finding latest version of hashicorp/aws...
- Installing hashicorp/aws v3.3.0...
- Installed hashicorp/aws v3.3.0 (signed by HashiCorp)

$ AWS_DEFAULT_REGION=us-west-2 terraform validate
Error: Computed attribute cannot be set

  on main.tf line 11, in resource "aws_s3_bucket" "backup":
  11:   region = data.aws_region.alt.name
4

Remove region since new version seems to remove this paremeter.
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/s3_bucket

1 Like
5

Indeed, as @rice7646 noted this is the result of the completion of a deprecation cycle for that argument, which is now always forced to match the region configured in the provider. There’s more information on this in the AWS provider v3 upgrade guide.

This problem is therefore not really specific to re-usable modules, but is rather just a major version upgrade step for the AWS provider. If your intent is to write a module that could potentially be compatible with AWS provider v2 and v3, I think it would suffice to remove the region argument and let the provider = aws.alternative_region argument indirectly set your alternative region. I believe the region argument was optional in AWS provider v2, as part of its deprecation process, so a module that omits it should be compatible with both versions.

1 Like
6

Ah right. Removing region makes validation pass :white_check_mark:

1 Like