starred/terravision

Fork 0

mirror of https://github.com/patrickchugh/terravision.git synced 2026-05-09 08:25:25 +02:00

[GH-ISSUE #187] TerraVision with highly Modularised Terraform #112

New issue

Closed

opened 2026-05-06 12:37:36 +02:00 by BreizhHardware · 7 comments

BreizhHardware commented

2026-05-06 12:37:36 +02:00

Owner

Originally created by @mkhan-kyn on GitHub (Apr 13, 2026).
Original GitHub issue: https://github.com/patrickchugh/terravision/issues/187

Originally assigned to: @patrickchugh on GitHub.

Hello Patrick,

I ran TerraVision on Docker by using outfile (tfplan.json) and graph (tfgraph.json), it executed without any error and outputs a draw.io file however, the generated diagram is far from reality. It displays empty subnets although the subnets do have resources, absent resource names and communication paths. The only correct thing in the diagram is the VPC CIDR, the subnets and the number of subnets - but even their resource names are not captured correctly.

My environment is highly modularised and variabliased i.e., extensive use of *.tfvars, locals and data sources so I was wondering if there's an issue with generating diagrams for complex deployments OR if there is something I am missing.

See below:

Note that I also tried running without the outfile & graph.dot still the generated diagram was same.

Thanks.

Originally created by @mkhan-kyn on GitHub (Apr 13, 2026). Original GitHub issue: https://github.com/patrickchugh/terravision/issues/187 Originally assigned to: @patrickchugh on GitHub. Hello Patrick, I ran TerraVision on Docker by using outfile (tfplan.json) and graph (tfgraph.json), it executed without any error and outputs a draw.io file however, the generated diagram is far from reality. It displays empty subnets although the subnets do have resources, absent resource names and communication paths. The only correct thing in the diagram is the VPC CIDR, the subnets and the number of subnets - but even their resource names are not captured correctly. My environment is highly modularised and variabliased i.e., extensive use of *.tfvars, locals and data sources so I was wondering if there's an issue with generating diagrams for complex deployments OR if there is something I am missing. See below: <img width="16384" height="1731" alt="Image" src="https://github.com/user-attachments/assets/e4f5c57e-317c-4dcd-b4cb-fd8816efb83a" /> <img width="792" height="704" alt="Image" src="https://github.com/user-attachments/assets/a985db06-5509-4415-a2c0-e33257994a65" /> Note that I also tried running without the outfile & graph.dot still the generated diagram was same. Thanks.

BreizhHardware closed this issue

2026-05-06 12:37:36 +02:00

BreizhHardware commented

2026-05-06 12:37:36 +02:00

Author

Owner

@patrickchugh commented on GitHub (Apr 13, 2026):

Thanks for sharing this finding @mkhan-kyn I would like to fix this right away. Can you run terravision with the --debug flag and share the tfdata.json dump file ? Feel free to do a find/ replace on any account ARN or data you wish to mask.

Thanks
P.

@patrickchugh commented on GitHub (Apr 13, 2026): Thanks for sharing this finding @mkhan-kyn I would like to fix this right away. Can you run terravision with the --debug flag and share the tfdata.json dump file ? Feel free to do a find/ replace on any account ARN or data you wish to mask. Thanks P.

BreizhHardware commented

2026-05-06 12:37:37 +02:00

Author

Owner

@mkhan-kyn commented on GitHub (Apr 14, 2026):

Thanks. Please, see attached.

tfdata.json

@mkhan-kyn commented on GitHub (Apr 14, 2026): Thanks. Please, see attached. [tfdata.json](https://github.com/user-attachments/files/26692047/tfdata.json)

BreizhHardware commented

2026-05-06 12:37:37 +02:00

Author

Owner

@patrickchugh commented on GitHub (Apr 14, 2026):

Hi @mkhan-kyn — thanks for the detailed report and the debug tfdata.json; that was invaluable for reproducing the issue.

Your stack hit a combination no other user had triggered: subnet/LB IDs flowing through deeply-nested locals (local.subnets.canonical.az1.pvt) that our interpreter couldn't evaluate, so the plan carried only resolved AWS IDs that weren't being ID-matched against graph nodes. You were also using AWS's newer regional NAT gateway (availability_mode = "regional") which we hadn't come across before — it has subnet_id = null by design, with per-AZ details under regional_nat_gateway_address[] instead, so we weren't placing it correctly.

Fixed in v0.34.0: ID-based placement, regional NAT handling, route-table-based public-subnet detection, LB per-subnet expansion with AZ pairing, VPC→AZ→subnet hierarchy rebuild, and cleaner labels. A regression test using your tfdata.json is now locked in.

Re-running against your fixture produces the diagram below. Could you pull LATEST ver and confirm it matches your real infrastructure?

@patrickchugh commented on GitHub (Apr 14, 2026): Hi @mkhan-kyn — thanks for the detailed report and the debug tfdata.json; that was invaluable for reproducing the issue. Your stack hit a combination no other user had triggered: subnet/LB IDs flowing through deeply-nested locals (local.subnets.canonical.az1.pvt) that our interpreter couldn't evaluate, so the plan carried only resolved AWS IDs that weren't being ID-matched against graph nodes. You were also using AWS's newer regional NAT gateway (availability_mode = "regional") which we hadn't come across before — it has subnet_id = null by design, with per-AZ details under regional_nat_gateway_address[] instead, so we weren't placing it correctly. Fixed in [v0.34.0](https://github.com/patrickchugh/terravision/releases/tag/v0.34.0): ID-based placement, regional NAT handling, route-table-based public-subnet detection, LB per-subnet expansion with AZ pairing, VPC→AZ→subnet hierarchy rebuild, and cleaner labels. A regression test using your tfdata.json is now locked in. Re-running against your fixture produces the diagram below. Could you pull LATEST ver and confirm it matches your real infrastructure? <img width="12217" height="4655" alt="Image" src="https://github.com/user-attachments/assets/ee3066fe-a844-438d-a00f-da476bf68bab" />

BreizhHardware commented

2026-05-06 12:37:37 +02:00

Author

Owner

@mkhan-kyn commented on GitHub (Apr 15, 2026):

Thanks @patrickchugh for quick response. I can say it is much better depiction of the infrastructure however, would've been great to have the actual/deployed resource names on the components.

I am guessing it can be refined by using Ollama?

https://github.com/patrickchugh/terravision?tab=readme-ov-file#ai-powered-annotations

@mkhan-kyn commented on GitHub (Apr 15, 2026): Thanks @patrickchugh for quick response. I can say it is much better depiction of the infrastructure however, would've been great to have the actual/deployed resource names on the components. I am guessing it can be refined by using Ollama? https://github.com/patrickchugh/terravision?tab=readme-ov-file#ai-powered-annotations

BreizhHardware commented

2026-05-06 12:37:37 +02:00

Author

Owner

@patrickchugh commented on GitHub (Apr 15, 2026):

Good idea @mkhan-kyn I assume you mean full terraform resources names underneath each resource instead of the generated capitalised labels that terravision generated ? Maybe I can add an option to --use-tf-names to show a different label for your case?

FYI You can also use user annotations in a terravision.yml file of your own to supplement as necessary without using LLMs.

@patrickchugh commented on GitHub (Apr 15, 2026): Good idea @mkhan-kyn I assume you mean full terraform resources names underneath each resource instead of the generated capitalised labels that terravision generated ? Maybe I can add an option to --use-tf-names to show a different label for your case? FYI You can also use user annotations in a terravision.yml file of your own to supplement as necessary without using LLMs.

BreizhHardware commented

2026-05-06 12:37:37 +02:00

Author

Owner

@mkhan-kyn commented on GitHub (Apr 15, 2026):

Hi @patrickchugh - yep that's what I meant. The diagram would be more presentable/relatable that way.

I will try the terravision.yml out soon and will also try to link LLM.

Thanks.

@mkhan-kyn commented on GitHub (Apr 15, 2026): Hi @patrickchugh - yep that's what I meant. The diagram would be more presentable/relatable that way. I will try the `terravision.yml ` out soon and will also try to link LLM. Thanks.

BreizhHardware commented

2026-05-06 12:37:38 +02:00

Author

Owner

@patrickchugh commented on GitHub (Apr 15, 2026):

Hi @mkhan-kyn I added a new option --use-tf-names in the latest code now so closing this issue.

@patrickchugh commented on GitHub (Apr 15, 2026): Hi @mkhan-kyn I added a new option --use-tf-names in the latest code now so closing this issue.