ambiguous moved statements in iam-role-for-service-accounts/migrations.tf

[jordanb-afs]

Recently tried upgrading to 6.0.0 version of this module and immediately ran into this issue. it seems multiple moved statements are all pointing to the same thing:

│ Error: Ambiguous move statements
│
│   on .terraform/modules/eks_cluster.ebs_csi_irsa_role/modules/iam-role-for-service-accounts/migrations.tf line 160:
│  160: moved {
│
│ A statement at .terraform/modules/eks_cluster.ebs_csi_irsa_role/modules/iam-role-for-service-accounts/migrations.tf:6,1 declared that
│ module.eks_cluster[0].module.ebs_csi_irsa_role.aws_iam_policy.aws_gateway_controller moved to module.eks_cluster[0].module.ebs_csi_irsa_role.aws_iam_policy.this, but this statement instead declares that
│ module.eks_cluster[0].module.ebs_csi_irsa_role.aws_iam_policy.vpc_cni moved there.
│
│ Each resource can have moved from only one source resource.
╵
╷
│ Error: Ambiguous move statements
│
│   on .terraform/modules/eks_cluster.ebs_csi_irsa_role/modules/iam-role-for-service-accounts/migrations.tf line 165:
│  165: moved {
│
│ A statement at .terraform/modules/eks_cluster.ebs_csi_irsa_role/modules/iam-role-for-service-accounts/migrations.tf:6,1 declared that
│ module.eks_cluster[0].module.ebs_csi_irsa_role.aws_iam_policy.aws_gateway_controller moved to module.eks_cluster[0].module.ebs_csi_irsa_role.aws_iam_policy.this, but this statement instead declares that
│ module.eks_cluster[0].module.ebs_csi_irsa_role.aws_iam_role_policy_attachment.vpc_cni moved there.
│
│ Each resource can have moved from only one source resource.
╵

[bryantbiggs]

We'll need a reproduction in order to assist

[jordanb-afs]

You can simply load the module with almost anything to reproduce it. AFAIK, it's invalid terraform to have multiple "moved" statements pointing to the same thing.

provider "aws" {
  region = "us-east-2"
}

terraform {
  required_version = "> 1.3"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}
module "ebs_csi_irsa_role" {
  source                = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts"
  name                  = "ebs-csi-testenv"
  attach_ebs_csi_policy = true
  oidc_providers = {
    test = {
      provider_arn               = "test"
      namespace_service_accounts = ["test"]
    }
  }
}

[bryantbiggs]

hmmm, ok - not sure why that didn't get picked up. I might get to this later tonight or worst case tomorrow morning

[Souldiv]

Facing the same issue

[rgasper]

Can confirm I am also experiencing this issue running plan

Error: Ambiguous move statements
  │ 
  │   on .terraform/modules/karpenter_irsa/modules/iam-role-for-service-accounts/migrations.tf line 160:
  │  160: moved {

# .terraform/modules/karpenter_irsa/modules/iam-role-for-service-accounts/migrations.tf
################################################################################
# Migrations: v5.60 -> v6.0
################################################################################

# AWS Gateway Controller
moved {
  from = aws_iam_policy.aws_gateway_controller
  to   = aws_iam_policy.this
}

moved {
  from = aws_iam_role_policy_attachment.aws_gateway_controller
  to   = aws_iam_policy.this
}

# Cert Manager
moved {
  from = aws_iam_policy.cert_manager
  to   = aws_iam_policy.this
}

moved {
  from = aws_iam_role_policy_attachment.cert_manager
  to   = aws_iam_policy.this
}

# Cluster Autoscaler
moved {
  from = aws_iam_policy.cluster_autoscaler
  to   = aws_iam_policy.this
}

moved {
  from = aws_iam_role_policy_attachment.cluster_autoscaler
  to   = aws_iam_policy.this
}

# ... more of the same pattern

[kaiyuanlim-adh]

We also have the same issue as well.

[lukaspj]

Previously this module would create one IAM Policy per "function"
I.e. one for Velero, one for VPC CNI etc.

Now it instead merges all the IAM Policies into a single document. This creates a many-to-one conflict as it is trying to merge all the different documents into a single one and Terraform doesn't support that so it is a breaking change.

As discussed in #588 I believe the only way forward is to delete the migrations altogether and let people recreate the IAM Policies or write their own migrations. (e.g. if you previously had one invocation of this module for 3 different policies, you can invoke this module once for each policy and migrate the state to this new module invocation).

[n00b-t00b]

To add a bit more context, this occurs even when using this module for a completely new deployment not just upgrades

[bryantbiggs]

we're looking into this