Dear Users,
We have fairly big terraform estate which is going through some fairly big re-writing. We are creating a complete new code-base. However, we have some resources (like IAM) that we can’t delete and re-create. What we instead want is to ‘import’ them into the new code-base. The new code-base will have different state-file than the old one.
My question is, if it would be safe to import a resource so it exists in both code-bases ?
For example, an IAM role is there in the old-code base and hence in the old state file. We have the same IAM role in the new code base too but we can’t obviously apply it as it fails due to multiple IAM Roles with same name can’t exist within same AWS Account. Instead, what we plan to do it first import the IAM role in the new state and then run plan/apply in the new code base.
Will it be safe ? Especially if the old-code base is also terraform applied (without any code-changes) multiple times ?
You can get away with this if you are absolutely certain no-one is going to make any changes which result in a change to the resource, in either the old or the new codebase, ever, until the old codebase is retired - but given the inflexibility of this restriction, and the ease of accidentally violating it, this is very much not a recommended setup at all.
A better way to deal with this is to make sure only one codebase is managing each resource.
If the codebase not currently managing the resource needs to refer to it, for example to reference it from other resources, use data blocks to look it up so you can reference it that way.
When the time comes to move it across, you can terraform state rm it from the old state and remove the resource block from the old codebase - then change the data to a resource in the new codebase, update references as needed, and terraform import. (And add the data approach to the old codebase if you still need to reference it there.)
In this way, it’s always clear which codebase is managing each resource.