Feature request: support -target in terraform graph

[clebio]

Terraform Version

$ terraform -v
Terraform v0.11.3

Feature request: support -target in graph. e.g. terraform graph -target=module.appX

That's pretty much it. I searched existing issues and didn't find this. Apologies if I missed a prior discussion.

[apparentlymart]

Hi @clebio!

This seems like a fine idea to me! We're currently focused on configuration language improvements rather than CLI changes, so we won't be able to look at this immediately but we will look at when we shift our focus to CLI improvements after the current set of work is complete.

In the mean time, you may be able to exploit terraform graph's ability to render a graph for a saved plan to approximate what you're looking for here:

$ terraform plan -out=tfplan -target=module.appX
...
$ terraform graph tfplan
...

Since the non-targeted items should be excluded from the apply graph for that plan, this should give you something like the filtered graph you seek. (It will not be identical, since the apply graph has some other differences, like having count-using resources already expanded to individual nodes.)

[mkohn]

+1

[btribit]

+1

[unacceptable]

@mkohn, @btribit Can you all turn those +1's into 👍's? https://help.github.com/en/articles/about-conversations-on-github#reacting-to-ideas-in-comments

It will make it easier for contributors to filter by popular feature requests.

[gatestone]

How about if you have a running system? Command plan will not output anything...

[apparentlymart]

I think at the time I originally wrote this Terraform had a different graph-building strategy where an "apply graph" still included everything and then the individual graph nodes just skipped taking any action if there was nothing for them in the plan, but indeed in modern Terraform the apply graph (which is what terraform graph with a saved plan file produces) includes only the subset of resources with actions recorded in the plan, and so that technique wouldn't work so well today.

I must admit I'd forgotten about this issue in the meantime because it's been a long time. Terraform's internal architecture has matured and is now somewhat more specialized to meet the "main" use-cases that are part of the everyday workflow, and so I don't think this would be so easy to implement today as it might've been back in Feb 2018.

In order to prioritize this, it would help if some of the folks who participated here or upvoted the issue could share some information about what underlying need they'd be meeting by generating a Graphviz representation of a plan graph. Terraform's execution graphs are essentially an implementation detail of Terraform and so we tend to think of terraform graph as just being a debugging tool, but if you all have other use-cases in mind and can describe them in terms of a problem to be solved rather than a specific technical proposal to address it then we may be able to meet the need in some other way that could potentially then be a supported integration point covered by compatibility promises, rather than a debugging tool subject to change in future releases.

Thanks!

[clebio]

In order to prioritize this, it would help if some of the folks who participated here or upvoted the issue could share some information about what underlying need they'd be meeting ... if you all have other use-cases in mind and can describe them in terms of a problem to be solved rather than a specific technical proposal

Hi Martin, @apparentlymart, thanks for the note! I'll admit that since I filed this issue it's partially escaped me what specific use case I had at the time. However, I will say that reasoning about and debugging large configurations is a recurring need and one where Terraform's native tooling is a bit light.

To hand-wave some use cases:

• search module calls to find uses of a resource type, accounting for conditional and repeated resources (i.e. count or for_each)
• filter a configuration for resources which do or don't specify a particular attribute key or value
• reasoning about state manipulations, such as lifting a set of resources into a new module, moving modules within a configuration, or adding iteration to a module

Visual representations are really useful in working with very large Terraform configurations, but quickly become illegible. Filtering, subsetting, and grouping would be invaluable (collapse a module to a single block, for instance). By "very large", let's say an order of magnitude more resources than this excellent example from the awesome blast-radius.

[apparentlymart]

While I know it's far from a universally-useful answer here, and knowing that its capabilities are still growing and doesn't cover everything yet, I did want to note that text editor plugins which use the Terraform language server, such as the Visual Studio Code extension, could potentially help with the subset of concerns that is related to navigating references in configuration.

The language server is an independent codebase from Terraform CLI and is evolving separately, so I can't promise here that it'll meet all potential use-cases -- and it certainly can't help with things that primarily involve the state, since it's focused on working with configuration -- but I wanted to note it in case it is useful for some use-cases that folks may have. If there's something it could potentially do (within the usual bounds of what text editors and IDEs support for source navigation) but doesn't do yet, you could also potentially open a feature request for the language server which may be able to prioritize meeting the need sooner than we could prioritize improvements to terraform graph here.

[gatestone]

My use case is just trying to understand and explain a largish cloud setup when everything is new to me. Something the contractors and consulting gurus left behind... :-)

[IkePCampbell]

Any traction on this?

[pingyeh]

The graph is too big for my resources to be renderable in PNG. Yeah I'm using SVG now.

$ tf graph | dot -Tpng -o /tmp/foo.png
dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.482378 to fit

I'm interested in several sub-graphs:

1. A graph for everything in the state right now
2. A graph for the current plan
3. A graph starting with a specified target node, where the target can be a prefix like module.foo to include every resource defined by the foo module.

[tomaszkubat]

+1

[apparentlymart]

In Terraform v1.7.0 and later, terraform graph now defaults to emitting a simplified graph that only describes the relationships between resources, ignoring the intermediate nodes like input variables and output values, because resources are the only objects that represent externally-visible side-effects where ordering is most significant.

Today's output should therefore be considerably more straightforward than was true when this issue was opened. I'm curious to know if the new simplified approach has helped make the output more understandable for larger configurations.

[mcmanustfj]

I can confirm that on mine (terraform state list | wc -l = 374) terraform graph is still very hard to use without a targeted plan (and if I'm not changing anything yet I can't make a plan)

[nightpool]

No, yeah, the graph changes don't really help at all. I'm still waiting on a single-target graph to try and understand my dependency ordering

[nightpool]

I think at the time I originally wrote this Terraform had a different graph-building strategy where an "apply graph" still included everything and then the individual graph nodes just skipped taking any action if there was nothing for them in the plan, but indeed in modern Terraform the apply graph (which is what terraform graph with a saved plan file produces) includes only the subset of resources with actions recorded in the plan, and so that technique wouldn't work so well today.

Is this still true? I can't reproduce this on Terraform 1.10