Open Lasering opened 6 years ago
Hi @Lasering! Thanks for this feature request.
At this time the architecture of Terraform makes this sort of optimization impossible, because providers are the component that knows the relationships between resources but core is the component that builds and optimizes the graph.
We can potentially add new interfaces to the provider API to allow the provider to give Terraform hints about such optimizations, but that is not an easy change and so is not something we'll be able to work on in the short term.
The mechanisms required for this are similar to what would be required to implement batch request optimizations as discussed in #7388: the providers would need to be able to give Terraform Core information about optimization opportunities, which the graph builder would then use to find the optimal way to execute a particular set of actions.
The general idea of batch requests is probably more broadly applicable than the sort of pruning you describe here, since very few resources in Terraform have this sort of "container" relationship where you can delete the container and implicitly delete the contents. Therefore it's likely that we'd implement batch requests first, but when we get to that (which will require some design/prototyping phases first, to see what design tradeoffs to make) we can also consider this use-case and how we might be able to support it with a similar mechanism.
Thanks again for opening this!
This is the best solution I found to circumvent the problem:
terraform state rm $(terraform state list | grep "openstack_networking_secgroup_rule_v2" | tr '\n' ' ')
terraform destroy
It assumes you want to destroy the entire security group.
I have a terraform recipe using
openstack_networking_secgroup_v2
andopenstack_networking_secgroup_rule_v2
(openstack is just an example). And I have a lot of rules (about 100 rules). Whenever I ask terraform to destroy my infrastructure he will dutifully destroy every rule, one by one, and then destroy the security group.If the end result is to destroy the entire security group then its pointless to destroy each rule individually. Or in other words the following optimization could be made:
I opened this issue at the Openstack provider and has redirected here.
This could be implemented in each provider or an extra key could be added to the meta-parameter lifecycle.