Using the consul_keys
resource would be the way to go here, otherwise, consul_key_prefix
will overwrite whatever changes were made by a user.
Now the tricky part as you've stated is how to handle use case no 2. Considering the following statements:
If the config is still the old default value, upgrade it to the new default value.
This would be handled by Terraform, once you update your variable definition, those new changes will be automatically applied.
If the user has changed it, don't mess with it.
This is where it gets complicated. Depending on the Terraform version you use, you could use a precondition block in combination with a data
block.
I think defining a new key/property here /app/stackname/
named like is_user_managed
could help.
By using a data source block you could retrieve the value set (true or false) and then reference it in the precondition block of the resource.
data "consul_keys" "is_user_managed" {
key {
name = "is_user_managed"
path = "/app/stackname/is_user_managed"
default = "false"
}
}
resource "consul_keys" "this" {
...
lifecycle {
precondition {
condition = data.consul_keys.var.is_user_managed == "false"
error_message = "This resource is being managed by an external identity"
}
}
}
Now the downside of this approach is that if the condition is not met, it'll block all the operations(which can be easily solved by going into Consul and setting the value to "false"), so it really depends on how your code is structured.
Another idea is to get the KV (/app/stackname/is_user_managed
) using the consul CLI, and then based on the result of that run Terraform using the target flag which it's not recommended.