Hello,
What is the best way to deal with conflicts between attributes in different resources? Within a resource there is the ConflictsWith field that can provide a plan time check for conflicting attributes being set. What about with attributes in different resources? Currently, we can pass this check off to the backend API and assume we will get an error if the user sets an invalid configuration. However, I was wondering if there is anything I can do on the Terraform side (preferably at plan time) to check for these sorts of conflicts?
Hi @CyrusJavan,
In Terraform’s current model each resource instance is distinct from all others, so there is no way to implement validation rules for the interactions between different resource instances. In larger systems, resources for the same provider can end up decomposed into separate Terraform configurations anyway, in which case there would be no single Terraform process that could “see” all of the context in order to implement those rules: the remote system is the only layer that has all of the context required to implement it.
For now then, this sort of rule tends to be an example of a check that can only happen at apply time, when the full context is available (in the remote system) to check it.
With that said, I’d be interested to hear more about the situation you’re trying to model, because we’ve had some discussions in the past about some ways the provider model could evolve in future to allow certain kinds of cross-resource constraints – for example, detecting that two resource instances in the configuration both declare the same object – and so we could add your use-cases into the mix and see if there’s a possible future design that could accommodate them.
@apparentlymart Thanks for the reply! That is what I suspected.
Our situation is similar to that of the AWS provider Security Groups and Security Group Rules. In which attributes of a resource can be defined inline with the resource itself or as standalone resources. In our case it is VPC attachments, that were initially designed as inline attributes, then later broken out.
A use case we have is actually that our existing API has a ‘default’ flag that when set on a resource updates all resources to mark the current one as a default. So the server will never reject conflicts of having more than one default, it’s just in-deterministic which one will win.
If we could validate all resources declared (for a specific provider instantiation), we could detect this case and throw an error.