28mm
commented
6 years ago Hi @m4h3 -- you raise some interesting issues :) My somewhat disorganized thoughts follow below.
Right now, blast-radius parses terraform graph to learn about the graph, so in a certain sense it only knows about the future--i.e. what the current state would be if terraform apply were run.
To learn about the deployment's current state, it would need to be able to parse .tfstate files, and assemble a graph from that.
I think dynamic mutations will be very hard, unless the initial and final states are known. This difficulty arises because blast-radius relies on graphviz for layout. Small changes to a graph can lead graphviz to wildly alter its layout, so it would be dizzying to watch terraform apply execute, for instance.
However, if initial and end states are known (by comparing.tfstate with terraform graph) it becomes possible to do a layout that includes everything, and simply reveal elements as they're instantiated in the cloud. I'm optimistic about this approach.
Some possible 1st steps
- A [referesh] button that activates when the configuration changes on disk.
- The option to view the graph as derived from
.tfstate, rather thanterraform graph - A
terraform planview
Anyway, those are some thoughts so far--I'll probably return with revisions. Let me know if I can clarify any particular point.
I've been following this project from the beginning and this is very interesting. You've thought about this before in a blog post : It would be nice to have an option to monitor the terraform state file and mutate the graph when things are getting deployed.
I'm wondering how the current architecture is ready for this.