Hi @rquadling,
What you are trying to do here is what resource for_each is for. It’s a feature in the same spirit as count (and mutually exclusive with it), where rather than creating a number of instances identified by consecutive integers it instead creates a number of instances corresponding to elements in a given map, using the map keys as the identifiers.
You didn’t show a full example of what var.cnames looks like but I’m inferring from your example that it at least has an attribute subdomain which you’d like to have as your key. In which case, the initial declaration with for_each could look like this:
resource "cloudflare_record" "cname" {
for_each = { for cn in var.cnames : cn.subdomain => cn }
# ...
}
That for_each expression is a for expression to transform your list of objects into a map of objects, using the subdomain attribute as the map key.
In the rest of the configuration you can use each.value to refer to a particular attribute of the current element of var.cnames. For example, you could use each.value.subdomain to access the subdomain attribute.
This will result in resources with addresses like this:
cloudflare_record.cname["foo"]cloudflare_record.cname["bar"]
…where “foo” and “bar” are example values for subdomain in your var.cnames. Adding and removing items from that list should then have the result you were looking for, as long as you ensure that the subdomain values are unique across the entire list.
You might find it interesting to refer to the modules in the terraformdns organization, where I was experimenting with modules to abstract over the differences between different DNS providers. I didn’t try the cloudflare provider yet (I’ve been busy with other things recently so not had time to continue work on that) but maybe some of the others will show some interesting patterns to further generalize your DNS module.
(I originally wrote those prior to the introduction of the resource for_each feature, so not all of them are updated to use it: some of them are still using count, with the same limitation you encountered here. The patterns for constructing the collections of objects to deal with the modelling differences between the different DNS hosting vendors may still be interesting though, if adapted to use for_each instead of count.)