Thanks for the idea. The Resources view is intentionally an inventory of resources Spacelift manages, and data sources are read-only lookups rather than managed state, so this would be a meaningful scope change. With only one vote since filing we can’t justify it right now, so I’m closing. If there’s a concrete job you’re trying to do (auditing what a stack reads, for example), describe it here and we’ll reconsider from that angle.
Natalia Gazda
Team•
Jun 19, 2025
Hi Nathaniel,
Thanks for sharing this use case. I can see how the current view made this confusing during your migration work.
To clarify - the Resources view is specifically designed to show managed resources (things Terraform creates, updates, and destroys). Data sources are fundamentally different - they're read-only queries that fetch information from existing infrastructure, not resources that Terraform manages.
You mentioned needing to determine "the source of the resources and outputs" during your migration. I'm curious about this - since the Resources view doesn't show dependencies or relationships between items, how would seeing data sources in the list help you trace where outputs are coming from?
When you were comparing terraform state across stacks during the migration, what specific decisions were you trying to make? What made you expect to see data sources there, and what impact did not seeing them have on your migration process?
I'm particularly interested in understanding the connection you see between data sources and being able to determine the source of outputs. What would seeing data.aws_ami.latest in a flat list tell you about which outputs depend on it?
Understanding these details would really help us grasp what problem you were trying to solve and whether there's a deeper visibility gap we should be thinking about.
Black Breeze
•
May 10, 2025
👋 Thanks for the suggestion! To help us understand the real job here—could you share a bit more context?
Specifically:
What would seeing data sources in the Resources view help you do?
Are you trying to debug something, understand dependencies, or ensure certain references exist?
What’s hard about the current experience?
Right now, we only show provisioned resources—things created by OpenTofu/Terraform. Data sources are different (they’re read-only), so we want to make sure we’re solving the right problem, not just adding noise.
Appreciate any examples or pain points you can share! 🙏
Coffee Starlight
•
Jun 18, 2025
We were doing resource and stack migrations and wanted to compare all resources in terraform state. We noticed that the resources view shows resources and outputs. Some of the outputs are coming from data sources. I do agree it can be more noise but in determining the source of the resources and outputs we were expecting to see all types of resources in state.
Log in to comment and vote
Comments4
Jonah Kowall
Jul 12
Thanks for the idea. The Resources view is intentionally an inventory of resources Spacelift manages, and data sources are read-only lookups rather than managed state, so this would be a meaningful scope change. With only one vote since filing we can’t justify it right now, so I’m closing. If there’s a concrete job you’re trying to do (auditing what a stack reads, for example), describe it here and we’ll reconsider from that angle.
Natalia Gazda
Jun 19, 2025
Hi Nathaniel,
Thanks for sharing this use case. I can see how the current view made this confusing during your migration work.
To clarify - the Resources view is specifically designed to show managed resources (things Terraform creates, updates, and destroys). Data sources are fundamentally different - they're read-only queries that fetch information from existing infrastructure, not resources that Terraform manages.
You mentioned needing to determine "the source of the resources and outputs" during your migration. I'm curious about this - since the Resources view doesn't show dependencies or relationships between items, how would seeing data sources in the list help you trace where outputs are coming from?
When you were comparing terraform state across stacks during the migration, what specific decisions were you trying to make? What made you expect to see data sources there, and what impact did not seeing them have on your migration process?
I'm particularly interested in understanding the connection you see between data sources and being able to determine the source of outputs. What would seeing
data.aws_ami.latestin a flat list tell you about which outputs depend on it?Understanding these details would really help us grasp what problem you were trying to solve and whether there's a deeper visibility gap we should be thinking about.
Black Breeze
May 10, 2025
👋 Thanks for the suggestion! To help us understand the real job here—could you share a bit more context?
Specifically:
What would seeing data sources in the Resources view help you do?
Are you trying to debug something, understand dependencies, or ensure certain references exist?
What’s hard about the current experience?
Right now, we only show provisioned resources—things created by OpenTofu/Terraform. Data sources are different (they’re read-only), so we want to make sure we’re solving the right problem, not just adding noise.
Appreciate any examples or pain points you can share! 🙏
Coffee Starlight
Jun 18, 2025
We were doing resource and stack migrations and wanted to compare all resources in terraform state. We noticed that the resources view shows resources and outputs. Some of the outputs are coming from data sources. I do agree it can be more noise but in determining the source of the resources and outputs we were expecting to see all types of resources in state.