Suggestion: aws_instance_state resource could solve a few issues

[hashibot]

This issue was originally opened by @gtmtech as hashicorp/terraform#12331. It was migrated here as part of the provider split. The original body of the issue is below.

---

For over 18 months, 2 issues which really hamper an immutable workflow strategy with terraform and aws mean that you have to orchestrate terraform itself.

The issues are hashicorp/terraform#2957 , and #190 , or #22

I imagine the reason that none of these have been tackled in a long time is that internally the dependency tree for terraform would need a large refactor, to cope with not just creation/destruction of resources, but also to put resources in other states (such as stopped) in order to remove an aws_volume_attachment resource.

I wondered if it might be good to create an aws_instance_state resource which might be able to help with all of these.

The aws_instance resource could therefore ensure the aws_instance is created. The aws_instance_state could ensure that it is started. And the aws_volume_attachment resource needs only to depend on aws_instance_state, and aws_instance_state to depend on aws_instance, and the destruction of an aws_volume_attachment resource would be easily possible with a destruction of an aws_instance_state resource (which would mean the instance is stopped).

I could see how you could fix a lot of state-related issues using this approach, although maybe there are other approaches being worked on. Its a real shame that these issues havent been addressed in such a long time however, as they would allow an extremely useful workflow of immutable OS + data disk , which would solve a lot of usecases without the need for an external tool to orchestrate terraform itself because its not capable of doing so itself at the moment.

[mark-r-m]

We could really really do with this!

[pawelsocha]

@radeksimko or @bflad - right now I'm considering to implement this resource.
But I need advice - this resource should working with a single instance or like AWS describe in documentation with multiple instances?

[bflad]

@pawelsocha thanks for your interest in taking this up -- I would suggest 1:1 resource:instance. Folks can use count or modules to span across multiple instances.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!