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

Invalid terraform when assume_role is set #171

Open
spar-eag opened this issue May 6, 2024 · 2 comments
Open

Invalid terraform when assume_role is set #171

spar-eag opened this issue May 6, 2024 · 2 comments
Labels
bug 🐛 An issue with the system

Comments

@spar-eag
Copy link

spar-eag commented May 6, 2024

Describe the Bug

When assume_role is set, the generated backend configuration is not valid. E.g.

module "terraform_state_backend" {
  source = "cloudposse/tfstate-backend/aws"
  version     = "1.4.1"
  namespace  = "test"
  name       = "tf-state"

  terraform_backend_config_file_path = "."
  terraform_backend_config_file_name = "backend.tf"
  role_arn = "<my role>"
}

results in the following configuration

terraform {
  required_version = ">= 1.0.0"

  backend "s3" {
    region  = "eu-central-1"
    bucket  = "test-tf-state"
    key     = "terraform.tfstate"
    profile = ""
    encrypt = "true"

    assume_role {
      role_arn = "<my role>"
    }

    dynamodb_table = "test-tf-state-lock"
  }
}

Applying this result in

Unsupported block type
│ 
│   on backend.tf line 11, in terraform:
│   11:     assume_role {
│ 
│ Blocks of type "assume_role" are not expected here. Did you mean to define argument "assume_role"? If so, use the equals
│ sign to assign it a value.

The generated code should actually be

terraform {
  required_version = ">= 1.0.0"

  backend "s3" {
    [...]
    assume_role = {
      role_arn = "<my role>"
    }
    [...]
}

i.e. an equal sign is missing. See https://developer.hashicorp.com/terraform/language/settings/backends/s3#assume-role-configuration.

Expected Behavior

I expect correct backend code to be generated.

Steps to Reproduce

See code example above.

Screenshots

No response

Environment

No response

Additional Context

No response

@spar-eag spar-eag added the bug 🐛 An issue with the system label May 6, 2024
@Nuru
Copy link
Contributor

Nuru commented May 22, 2024

I have been wanting to get rid of the generated configuration for a long time, as it is difficult to use and difficult to maintain. This was broken in #151 6 months ago, and if even the PR submitter didn't realize it was broken, then, to me, that is evidence that few people are using it and we can safely get rid of it.

@osterman What do you think?

@Gowiem
Copy link
Member

Gowiem commented Jul 4, 2024

@Nuru +1 on getting rid of it. It doesn't feel like it should be in scope of this module -- That's not a great way to manage backend configs.

@spar-eag if you put up a PR that removes this functionality altogether, then I'd be happy to review and we can bring it to the rest of the maintainer team to get their thoughts as well at that point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 An issue with the system
Projects
None yet
Development

No branches or pull requests

3 participants