terraform icon indicating copy to clipboard operation
terraform copied to clipboard

console unable to inspect module resources

Open staranto opened this issue 2 years ago • 4 comments

Terraform Version

Terraform v1.6.4
on linux_amd64
+ provider registry.terraform.io/hashicorp/random v3.5.1

# Also same results in 1.5.6.

Terraform Configuration Files

###  /main.tf
module "good" {
  source = "./modules"
}

resource "random_string" "root" {
  length  = 2
  special = false
  keepers = {
    ts = timestamp()
  }
}

### modules/main.tf
resource "random_string" "this" {
  length  = 2
  special = false
  keepers = {
    ts = timestamp()
  }
}

Debug Output

https://gist.github.com/staranto/896d17262a2058273b246522facfb1f1

Expected Behavior

I'd expect terraform console to allow me to inspect state resources created in modules. If this isn't the case, perhaps the console docs needs changed? In particular, this statement --

You can use it to test interpolations before using them in configurations and to interact with any values currently saved in state.

Actual Behavior

Error. See below.

Steps to Reproduce

# Clean.  No init or state.
> ls --tree
drwxrwxr-x   - 16 Nov 06:12 .
drwxrwxr-x   - 16 Nov 06:10 ├── modules
.rw-rw-r-- 108 16 Nov 06:10 │  └── main.tf
.rw-rw-r-- 150 16 Nov 06:08 └── main.tf

> terraform init

> terraform apply --auto-apply
...
Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

> terraform state list
random_string.root
module.good.random_string.this

# This works as expected
> echo 'random_string.root' | terraform console
{
  "id" = "D6"
  "keepers" = tomap({
    "ts" = "2023-11-16T11:16:27Z"
  })
  <snip>
}

# This fails.  Does console not support inspecting
# resources in modules?
echo 'module.good.random_string.this' | terraform console
╷
│ Error: Unsupported attribute
│ 
│   on <console-input> line 1:
│   (source code not available)
│ 
│ This object does not have an attribute named "random_string".

# Terraform recognizes that there is a module.good
> echo 'module.good' | terraform console
{}
> echo 'module.goodXXX' | terraform console
╷
│ Error: Reference to undeclared module
│ 
│   on <console-input> line 1:
│   (source code not available)
│ 
│ No module call named "goodXX" is declared in the root module. Did you mean "good"?

Additional Context

No response

References

No response

staranto avatar Nov 16 '23 11:11 staranto

Hi @staranto,

Thanks for filing the issue! That sentence should probably indicate that the "state" which you have access to is scoped to the root module. The expression syntax cannot traverse modules, and only has access to child module outputs. For any future additions to the language which might allow expressions with a different scope, you can follow #31861.

Thanks!

jbardin avatar Nov 16 '23 15:11 jbardin

At some point in the past terraform console did allow specifying a different module to use as the evaluation scope via a command line option. I don't remember off the top of my head why we ended up needing to remove that, but I suspect it has something to do with the changes we made to shrink state snapshots by no longer saving information about named value objects like local values and output values except for those in the root module.

I suspect we could probably find some way to restore that capability at least in part, possibly with a few caveats about certain data appearing as unknown values when evaluating in a non-root module. I think a next step here would be to try a prototype to relearn what the constraints are here; we might even find that the constraints today are not as severe as they were at the time, since we've made changes to our expression evaluator in the meantime.

Concretely, the sort of thing I mean is:

terraform console -scope=module.foo

...which would mean that any expressions evaluated in that console session would be evaluated in the scope of the given module instance, instead of the root module.

I think the original name for this option was "module" rather than "scope", but this more general name will leave the door open for e.g. allowing resource instances as scopes later, making each.key, etc available as they would be inside that resource block.

With all of that said, I would also guess that we wouldn't be able to prioritise this right now since everyone is already busy with other things. Voting 👍 on the original issue comment could influence that prioritization, by illustrating that lots of people would appreciate this new (or rather, restored) capability.

apparentlymart avatar Nov 16 '23 16:11 apparentlymart

Thank you @jbardin and @apparentlymart for your quick and thorough responses! I've up voted the original issue.

staranto avatar Nov 16 '23 22:11 staranto

As a work around, you can view the sub-module resources in the state file. (I'm using Terraform v1.7.4)

If you've never seen the state file before, resources aren't named wholly as you'd expect and are split as such:

{ "module": "module.networking.module.vpc", "mode": "managed", "type": "aws_route_table_association", "name": "private",

So you'll have to make use of a find utility to find your resource based on it's module or type or name if unique.

I agree this should be a feature - If it's saved in the same state file, why not have this ability for sub-modules, if it's available for modules.

connoravo avatar Feb 27 '24 14:02 connoravo

@jbardin FYI I removed the documentation label as this seems to be a feature request - let me know if I was misunderstanding and I can move this to the web-unified-docs repo.

crw avatar Aug 13 '25 00:08 crw