Suggestion: aws_instance_state resource could solve a few issues

[gtmtech]

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 #2957 , and #7262 , or #1579

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.

[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.