fix: Correct types in 6.0 moved blocks mismatch between aws_iam_policy and aws_iam_role_policy_attachment

[lukaspj]

Description

There seems to have been a copy-paste mistake in the migrations where aws_iam_policy type has been used as the "to" for aws_iam_role_policy_attachment resources.

Motivation and Context

We are seeing the following error:

│ Error: Move Resource State Not Supported
│ 
│ The "aws_iam_policy" resource type does not support moving resource state
│ across resource types.

Edit: This does not solve #586 as that is related to the change of merging all the policies into a single resource being a breaking change

Breaking Changes

How Has This Been Tested?

• I have updated at least one of the examples/* to demonstrate and validate my change(s)
• I have tested and validated these changes using one or more of the provided examples/* projects

• I have executed pre-commit run -a on my pull request

[botchk]

Appreciate the quick response. Just ran into this issue and tried to fix it locally myself with the same approach. But the proposed fix doesn't solve the underlying issue of multiple different resources trying to move to the same resource, which is something that Terraform doesn't like:

Error: Ambiguous move statements
 
   on .terraform/modules/cluster_autoscaler_irsa/modules/iam-role-for-service-accounts/migrations.tf line 165:
  165: moved {
 
A statement at .terraform/modules/cluster_autoscaler_irsa/modules/iam-role-for-service-accounts/migrations.tf:11,1 declared hat module.cluster_autoscaler_irsa.aws_iam_role_policy_attachment.aws_gateway_controller
moved to module.cluster_autoscaler_irsa.aws_iam_role_policy_attachment.this, but this statement instead declares that module.cluster_autoscaler_irsa.aws_iam_role_policy_attachment.vpc_cni moved there.

Each resource can have moved from only one source resource.

I don't know that the intended migration scenario was but looks like the migration concept needs to be revisited.

[lukaspj]

Ah right of course, and that's also why we haven't been encountering your issue because we only invoke this module once per policy.

I'd say isn't the best solution here to destroy the existing policies and recreate a new one instead of trying to migrate it?

[botchk]

I'd say isn't the best solution here to destroy the existing policies and recreate a new one instead of trying to migrate it?

Yes, I also agree that this is the best approach. Consumers can then still decide if they want to do a migration and add the relevant moved blocks themselves.

[lukaspj]

Tried destroying existing policies and recreating with the module as-is and got this error:

So I'd reckon this PR doesn't properly solve the problem. The only solution, as I see it, is to delete the migrations and force them to recreate their IAM Policies or write their own migrations..