Update moved
semantics to allow moving a resource managed by an attribute or inline block to a separate resource
#35785
Labels
Terraform Version
Use Cases
The AWS provider recently approved a proposal for a pattern that will be used going forward to manage "exclusive relationships" between resources. The first implementation of this pattern was for
aws_iam_role
and theiraws_iam_role_policy
attachments.I'm really excited about this new pattern, and would love to adopt it quickly. However, it introduces a dilemma for module authors. How do we refactor the module and minimize the migration pain for users? With the current features available in Terraform, module users would have to write
import
blocks for every attachment resource, which makes the refactoring backwards-incompatible and a major version bump.Attempted Solutions
To demonstrate the problem, I attempted to migrate a module we author to use the new exclusive pattern with the
aws_iam_role
andaws_iam_role_policy
resource. You can see that here, plus3it/terraform-aws-tardigrade-iam-principals#205. There's also a discussion of the migration options on the aws provider repo, hashicorp/terraform-provider-aws#39376 (comment).Proposal
I would like to propose an update for
moved
block semantics, allowing users to specify afrom
expression that uniquely identifies a resource managed by an inline block. Usingaws_iam_role
as an example, it might look like:Those semantics largely follow the idea of
import
requirements for the target resource type. For aninline_policy
block on anaws_iam_role
resource, we only need to know the inline policy name to map the state to the new resource.It occurs to me that
moved
does not currently support interpolation, or expressions, orfor_each
, the wayimport
does. Since these inline blocks do not have state addresses, I think this proposal would also require updates to extend that support tomoved
blocks. A complete example, to make my pr testing the migration to the exclusive resource simply a feature release, might look like this:And then similarly for attachments of managed policies (once that "exclusive" resource is available), I'd write something like
References
The text was updated successfully, but these errors were encountered: