Terraform: Graph output includes internal nodes

[sethvargo]

Terraform Version

0.9.5 - 0.11.7

Affected Resource(s)

• core

Terraform Configuration Files

resource "aws_instance" "web" {
  ami                    = "ami-12d8047d"
  instance_type          = "t2.micro"
  subnet_id              = "subnet-..."
  vpc_security_group_ids = ["sg-..."]
}

Expected Behavior

The output of terraform graph should closely match previous versions.

Actual Behavior

The output of terraform graph includes what appears to be internal nodes.

Steps to Reproduce

1. terraform graph

0.9.3 yields

digraph {
    compound = "true"
    newrank = "true"
    subgraph "root" {
        "[root] aws_instance.web" [label = "aws_instance.web", shape = "box"]
        "[root] provider.aws" [label = "provider.aws", shape = "diamond"]
        "[root] aws_instance.web" -> "[root] provider.aws"
    }
}

0.9.4 yields

digraph {
    compound = "true"
    newrank = "true"
    subgraph "root" {
        "[root] aws_instance.web" [label = "aws_instance.web", shape = "box"]
        "[root] provider.aws" [label = "provider.aws", shape = "diamond"]
        "[root] aws_instance.web" -> "[root] provider.aws"
        "[root] provider.aws (close)" -> "[root] aws_instance.web"
    }
}

0.9.5 yields

digraph {
    compound = "true"
    newrank = "true"
    subgraph "root" {
        "[root] aws_instance.web" [label = "aws_instance.web", shape = "box"]
        "[root] provider.aws" [label = "provider.aws", shape = "diamond"]
        "[root] aws_instance.web" -> "[root] provider.aws"
        "[root] meta.count-boundary (count boundary fixup)" -> "[root] aws_instance.web"
        "[root] provider.aws (close)" -> "[root] aws_instance.web"
        "[root] root" -> "[root] meta.count-boundary (count boundary fixup)"
        "[root] root" -> "[root] provider.aws (close)"
    }
}

[qrevel]

Any update on this issue?
The problem is still here in 0.9.10.

[apparentlymart]

Sorry for the silence here.

Unfortunately given that this issue is just cosmetic -- though I understand it's confusing! -- it has ended up lower on my list due to some other issues and work that have come up in the mean time. However, I do still intend to take a close look at this and try to rework slightly how we build these graphs so that we're not constantly accidentally disturbing them with changes to implementation details, and so that they are more useful as debugging, learning, and teaching tools.

I expect to be able to spend more time on this once we complete the 0.10 release cycle, since right now we're working on things that would otherwise need to wait until 0.11 due to compatibility concerns. Since the graph functionality is not part of the core workflow we can address this in a 0.10 point release.

[automaticgiant]

this might not be organized well enough, but anyway...

train of thought first:

• is there maybe an intermediate graph depiction that could be standardized?
• the information provided by the current graph subcommand is mostly implementation-related.
• tf knows more than various usages care about
• graph subcommand -type[s] are views
• if graph is a generalizable subcommand, may want pluggable graph types, or a supergraph that is reduced based on view/graphtype
• a standardized graph can be consumed in various ways, depending on application, like documentation, traffic-flow, powered by the standard supergraph

I'm interested in generating graphs from various things (configuration, tf, environment samples, designs) and coalescing them and generating subgraphs (views) from them.
None of the existing tf graph types suit my needs exactly, and/or are too potentially volatile (because design goals not aligned with my use case).
This speaks to a potential need for a "standardizable" (read more stable) information graph source in TF, which could be used to produce views for different use cases.

@apparentlymart When it's again time to bang on TF graphs, how do you feel about the so far thoughts/conclusions?

[jbardin]

Hi @automaticgiant,

I'm curious what you mean by an "intermediate graph depiction that could be standardized". We chose to serialize to dot, because that's the most easily consumable and standard format.

I'm also not sure what you mean by graphs of "various things". Terraform works with slightly different graphs depending on the associated operation, but they are all in essence the core dependency graph that drives terraform. The graph command isn't meant to produce generalized output for anything other than what terraform is going to operate on.

As you say, this may be a difference in design goals with what you're thinking, but there may be some overlap which we can take into consideration when we get time to fix up this command's output.

[automaticgiant]

@jbardin - intermediate meaning in between existing dot output and the resource graph.

i guess what i'm takling about is mostly emitted as the state (file), although it doesn't contain the discoverable dependencies between resources which the dependency graphs show, other than module heirarchy.

so i could combine state with graph output and maybe something else to graph things about the resources, but maybe just dumping the graph in full detail would be better? (unless using a particular graph type like plan or destroy).

the graph subcommand is really mostly only concerned with dependency graphs. and there are different supported dependency graphs to generate. if core workflow doesn't include helping generate visualizations/documentation of config/state (not necessarily saying it should), then being able to dump a more data-rich version of the graph might facilitate the "debugging, learning, and teaching tools" that @apparentlymart mentioned.

[dmitrytokarev]

Found out that last clean graph is actually produced by terraform ver 0.7.13.
(it only includes resources, ignores var and output)

Ver 0.8.0 includes outputs and vars in the graph and the internal nodes.

Workaround
If you don't want to manually cleanup your graph - quick dirty workaround is to use docker:
(must run from your terraform dir or sub $(dir) with absolute path to your terraform repo)
docker run -it --rm -v $(pwd):/tmp hashicorp/terraform:0.7.13 graph /tmp
then copy/paste to https://dreampuf.github.io/GraphvizOnline/
or
create svg image locally (macOS)

brew install graphviz 
docker run -it --rm -v $(pwd):/tmp hashicorp/terraform:0.7.13 graph /tmp | dot -Tsvg > graph.svg
open graph.svg

dot is the command for graphviz
install graphviz from here http://www.graphviz.org/download/

NOTE: more complex terraform settings using later version features (e.g. backends) will not let you generate clean graph with docker image terraform: 0.7.13.
So will need to manually cleanup graph output 😞

[joestump]

We just deployed a fix for this:

terraform graph -no-color | grep -v meta.count-boundary > plan.dot

[lawliet89]

I am on Terraform v0.11.8 and I still see count-boundary:

digraph {
    compound = "true"
    newrank = "true"
    subgraph "root" {
        "[root] aws_instance.instance" [label = "aws_instance.instance", shape = "box"]
        "[root] aws_security_group.instance" [label = "aws_security_group.instance", shape = "box"]
        "[root] aws_security_group_rule.ssh_inbound" [label = "aws_security_group_rule.ssh_inbound", shape = "box"]
        "[root] data.aws_ami.ubuntu" [label = "data.aws_ami.ubuntu", shape = "box"]
        "[root] provider.aws" [label = "provider.aws", shape = "diamond"]
        "[root] aws_instance.instance" -> "[root] aws_security_group.instance"
        "[root] aws_instance.instance" -> "[root] data.aws_ami.ubuntu"
        "[root] aws_instance.instance" -> "[root] var.instance_type"
        "[root] aws_instance.instance" -> "[root] var.ssh_key_name"
        "[root] aws_instance.instance" -> "[root] var.subnet_id"
        "[root] aws_security_group.instance" -> "[root] provider.aws"
        "[root] aws_security_group.instance" -> "[root] var.name"
        "[root] aws_security_group.instance" -> "[root] var.tags"
        "[root] aws_security_group.instance" -> "[root] var.vpc_id"
        "[root] aws_security_group_rule.ssh_inbound" -> "[root] aws_security_group.instance"
        "[root] aws_security_group_rule.ssh_inbound" -> "[root] var.ssh_cidr_blocks"
        "[root] data.aws_ami.ubuntu" -> "[root] provider.aws"
        "[root] meta.count-boundary (count boundary fixup)" -> "[root] aws_security_group_rule.ssh_inbound"
        "[root] meta.count-boundary (count boundary fixup)" -> "[root] output.private_ip"
        "[root] output.private_ip" -> "[root] aws_instance.instance"
        "[root] provider.aws (close)" -> "[root] aws_instance.instance"
        "[root] provider.aws (close)" -> "[root] aws_security_group_rule.ssh_inbound"
        "[root] provider.aws" -> "[root] var.aws_region"
        "[root] root" -> "[root] meta.count-boundary (count boundary fixup)"
        "[root] root" -> "[root] provider.aws (close)"
    }
}

[abitrolly]

Still there.

✗ terraform version 
Terraform v0.11.13
+ provider.aws v2.1.0

[MacFlurry]

Hello,
any update ?
thanks

[apparentlymart]

No, there have been no changes related to this issue.

Leaving extra comments doesn't do anything but create noise for those who are monitoring this issue. If you're interested in improvements here, please instead add a :+1: reaction to the opening comment in the issue (not to _this_ comment), which we report on and use as an input for prioritization.

[danieldreier]

I have reproduced this on 0.13.0 beta 1. I also noticed an additional bug in which the terraform graph output doesn't work with graphviz, which I reported as #25237 and is out of scope for this issue.

main.tf:

resource "null_resource" "test" {}

resulting dot file on 0.13.0:

digraph {
        compound = "true"
        newrank = "true"
        subgraph "root" {
                "[root] null_resource.test (expand)" [label = "null_resource.test", shape = "box"]
                "[root] provider["registry.terraform.io/hashicorp/null"]" [label = "provider[\"registry.terraform.io/hashicorp/null\"]", shape = "diamond"]
                "[root] meta.count-boundary (EachMode fixup)" -> "[root] null_resource.test (expand)"
                "[root] null_resource.test (expand)" -> "[root] provider["registry.terraform.io/hashicorp/null"]"
                "[root] provider["registry.terraform.io/hashicorp/null"] (close)" -> "[root] null_resource.test (expand)"
                "[root] root" -> "[root] meta.count-boundary (EachMode fixup)"
                "[root] root" -> "[root] provider["registry.terraform.io/hashicorp/null"] (close)"
        }
}

[apparentlymart]

Hi all! Sorry for the long silence here.

This issue is in a bit of an odd state because it was marked as "bug" very early in its life, but really it's not a bug: the terraform graph feature here is working as designed, because there's not currently any concept of "internal graph nodes" in Terraform Core: all graph nodes are the same, and terraform graph shows all of them.

This being marked as "bug" therefore isn't really helping anyone, because folks keep finding it and trying to attack it as a bug, spinning their wheels for a while looking for this "internal nodes" concept in our codebase, and then realizing that it's actually a new feature requiring a whole new concept to be introduced into Terraform Core.

With that in mind, I'm going to try to avoid this recurring loss of time by relabeling this as an enhancement, representing the idea of changing terraform graph's mission so that it's goal is to produce a curated representation of the graph focused primarily on user education, rather than its current purpose of showing the raw graphs exactly as Terraform will traverse them. If we move forward with that as the direction (which is still to be determined) then it could involve introducing this idea of "internal nodes" as the initial comment describes them, or it could involve separating this command from Terraform Core's main graph builders altogether and building a bespoke graph designed for education purposes, or somewhere in between.

Either way, that'll be for someone else to dig into as part of designing this feature once it's at the top of the priority list. As usual, you can influence the prioritization of issues by adding a :+1: reaction to the original opening comment (not to _this_ comment), which is one of the inputs the Terraform team uses to decide what to work on next.

Sorry again for the long silence, and also for this notification noise for folks who are subscribed to this. Thanks!

[abitrolly]

Is the a problem to add param to filter terraform graph to produce output for both internal purposes and user consumption?