3 ms·
You don't need to store the full old configuration anywhere other than as part of the current configuration. All you need is a list of IDs that existed in previ
by GeneralMayhem 4y ago
You don't need to store the full old configuration anywhere other than as part of the current configuration. All you need is a list of IDs that existed in previous configurations. Something like:
current_tables {
TableA {
Column1[string]
Column2[bool]
}
}
removed_tables: ["TableOld", "AnotherOldTable", ...]
Depending on your ergonomic preferences, you could also accomplish that by keeping the old table configs and adding an "is_deleted" flag. And once you've done one deploy, you can delete all the old tombstoned configs.
- pst 4y agoYes, but setting up and handling edge cases of Terraform state causes the effort. Once you have it, storing just IDs or more doesn't make a difference anymore.
- jen20 4y agoThat is a state file by any other name. Terraform could work this way with fairly trivial code changes, and the cost of blowing up provider rate limits during fast incremental development (the kind of places where you set -refresh=false).
- jvitor03 4y agoLooks like you are creating based on puppet or ansible, not Terraform :) The whole idea of TF is to not have to declare an absent resource for it to be destroyed, because the declarative approach already have the desired state.