I'm looking for the following experience:
- User Terraforms my stack. This causes default configuration stanzas to be populated in an according consul KV location, say /app/stackname/config.txt
- When I upgrade my code, let's say I have a new default config. If the config is still the old default value, upgrade it to the new default value. If the user has changed it, don't mess with it.
- If the KV config is missing, for whatever reason, repopulate it with the default
I'm having trouble managing this.
I've tried using consul_keys as both a data source and resource to detect if my value exists, but I'm unclear on how to handle case (2) above. consul_key_prefix seems too aggressive for my purposes. Any help appreciated.
Using the
consul_keysresource would be the way to go here, otherwise,consul_key_prefixwill 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:
This would be handled by Terraform, once you update your variable definition, those new changes will be automatically applied.
This is where it gets complicated. Depending on the Terraform version you use, you could use a precondition block in combination with a
datablock.I think defining a new key/property here
/app/stackname/named likeis_user_managedcould 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.
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.