terraform state show problem with similarily named resources

[Samuli Saarinen]

Hi,

Given following resources in state:

$ terraform state list aws_security_group.lb_sg

aws_security_group.lb_sg

module.blah.aws_security_group.lb_sg

How do I get the state of the resource that is not in the module? Using following does not work.

$ terraform state show aws_security_group.lb_sg
Multiple instances found for the given pattern!

Documentation for state show talks about Address but still expects a pattern?

$ terraform --version
Terraform v0.11.10
+ provider.aws v1.13.0
+ provider.random v1.2.0
+ provider.template v1.0.0

br,

Samuli

[Sander van Harmelen]

Hi Samuli,

That's a very good point! I'm currently updating (rewriting) the `state` commands to make them work in v0.12 and in general we try to keep the behavior of the commands inline with how they worked before v0.12. But we did make a few small improvements to hopefully fix a few small shortcomings.

One of those fixes is that when you try to use `state mv` to move a resource, we now first check if the source and destination resources are of the same type. Another one of those fixes will address the issue you just described, so the `state show` command will no longer use the input as a pattern but as a full address.

The last change will be that both the `state mv` and `state rm` commands now have a `-dry-run` flag that enables you to see what would have happened, before actually executing the commands.

I understand that this doesn't help you today as these fixes will not be back ported to v0.11.x, but I just wanted to let you know that we are working on fixing/improving this for the upcoming v0.12 release.

Best,

Sander

[Samuli Saarinen]

Hi Sander,

 

Thanks for your answer. This wasn’t that critical to me but wanted to know for future reference.

 

I think the dry-run flag will be a good addition. I also noticed that in situation I described when trying to `state mv aws_security_group.lb_sg module.xyz.aws_security_group.lb_sg` it seemed as though it also somehow affected the state of  module.blah.aws_security_group.lb_sg.

I did not have the time to test it thoroughly but given your explanation could it be the case that mv also uses the input as pattern instead of address and ends up modifying something that it should not?

 

cheers,

Samuli

 

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to a topic in the Google Groups "Terraform" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/terraform-tool/B6pN4izPS4g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to terraform-too...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/6401680b-fb56-4329-985c-00c40ebd800a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sander van Harmelen]

Hi Samuli,

I just had a look at this for the updated commands in v0.12. The `-dry-run` flag should give a conclusive preview of what the command will do. Additionally I updated the algorithm a bit to make sure the best match is used instead of the (after alphabetically ordering) first returned result. This should make the `mv` command more robust and intuitive.

Best,

Sander

To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/001001d46d26%2460364060%2420a2c120%24%40gmail.com.