Accept map or list for policy arns @Nuru (#198)
what
- Accept both map (
task_policy_arns_map,task_exec_policy_arns_map) and list (task_policy_arns,task_exec_policy_arns) inputs for policy ARNs. Supersedes and closes #196. - Add
depends_onforecs_serviceresource toaws_iam_role_policy.ecs_service.
why
History
- Issue #167 is typical behavior when supplying a list of inputs to convert into resources. The solution to it is to provide a map of resources, so that changes are limited to what is necessary according to the change in inputs. Adding to or removing from the list, or changing the order of the list, no longer affects the list items that did not change, because each item is now referenced by the key in the map rather than its index in the list.
- PR #178 tried to fix #167 by using the input values as keys. However, this created issue #191, because the values (IAM Policy ARNs) are generated by the
terraform applyand are therefore not known atplantime, which is a requirement. - PR #194 fixed #198, but re-introduced #167, because it simply replaced the implicit "list index as key" with an explicit one in the case of list inputs.
- PR #195 used the values as keys, but this just recreated #191, so it was abandoned
- PR #196 used a little-used provider that tries to let us have it both ways: it gives us #167 if the values are unknown at plan time but works well if the values are known at plan time. Unfortunately, this can render a plan non-deterministic. Even more importantly, it does not give a user whose values are unknown at plan time a way to avoid #167.
This Solution
With the solution provided by this PR, any user can avoid #167 by providing a map whose keys are known at plan time, regardless of whether the values are known at plan time. Policy ARNs could be labeled by name, purpose, region, or whatever the user wants to avoid #167. Or, if the user doesn't care about #167, perhaps because they are only supplying a single Policy ARN, then they can just supply it in a list.