[WIP] Allow searching by resource ID in terraform state list.

[korfuri]

This change adds an optional -id flag to terraform state list. When that flag is used, the output of the command is restricted
to resources whose ID is equal to the value of that flag.

This is useful to answer questions of the type "where in my configs is
this resource". These questions can arise in large Terraform setups,
where an operator looking at resources that exist on the
provider (e.g. via AWS console) may not always be able to tell why a
given resource exists.

[korfuri]

Hi maintainers! I've found myself needing to answer the question of "what the hell is sg-1234abcd for" during a somewhat large import operation (to find what a given security group rule was about). There didn't seem to be a way to do that other than grepping the state file, so I made one. I marked this PR as [WIP] because I don't think my approach (adding a flag to tf state list) is necessarily the best, it was just the most convenient on the spot. I considered adding a new command instead (e.g. tf state whereis) and there may be other options I'm not aware of.

I also don't know if it's worth making this more generic and allowing to search based on any property of a resource in the state, instead of just by ID. What do you think?

Thank you.

[apparentlymart]

Hi @korfuri! Thanks for working on this.

This is an interesting idea! Seems like it would be most useful for simple systems where everything is managed in a single Terraform configuration/state, since otherwise you wouldn't necessarily know which one to look in, but I'd assume in most cases with a complex, multi-state deployment you can infer from some context (like resource tags, etc) which subsystem a particular object belongs to.

In future we could potentially use Terraform's expression language to support the arbitrary filtering you were thinking about:

$ terraform state list -filter='id == "sg-1234abcd"'

...and that could be better in the long term because not all resource types have reasonable human-friendly values in the id attribute.

However, I think that sort of thing is best deferred until after we've finished integrating the new expression parser, since the current one is about to be replaced anyway and so implementing this -filter argument today would be throwaway work.

In the mean time, filtering by -id seems like a good pragmatic compromise that'll work for most resources that have a first-class identifier in the remote system.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.