Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

backend/local: don't panic when an instance has only a deposed object #21575

Merged
merged 1 commit into from
Jun 4, 2019

Conversation

apparentlymart
Copy link
Contributor

This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a create_before_destroy.

Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.

This fixes #21396.


Some additional context:

In working on this I noticed that in principle the specific situation I covered in the test here could be simplified to just a normal create_before_destroy in the UI, because that is effectively what's going to happen anyway.

However, the UI handling of deposed instances is generalized to deal with a bunch of other similar edge-cases around deposed instances. The main one it's dealing with is the situation where the "destroy" part of a create_before_destroy fails and thus the state ends up containing both a current instance and a deposed instance at the same time. If the user then updates the config again and triggers another create_before_destroy then the destroy can fail again and accumulate two deposed instances, like this:

Terraform will perform the following actions:

  # test_instance.foo will be replaced
+/- resource "test_instance" "foo" {
        ami = "bar" -> baz

        network_interface {
            description  = "Main network interface"
            device_index = 0
        }
    }

  # test_instance.foo (deposed object ABCDABCD) will be destroyed
  - resource "test_instance" "foo" {
      - ami = "bar" -> null

      - network_interface {
          - description  = "Main network interface" -> null
          - device_index = 0 -> null
        }
    }

  # test_instance.foo (deposed object DEFADEFA) will be destroyed
  - resource "test_instance" "foo" {
      - ami = "foo" -> null

      - network_interface {
          - description  = "Main network interface" -> null
          - device_index = 0 -> null
        }
    }

The above situation is also rare, but it's less rare (easier to run into) than the one this fix is aimed at, and so that's why the UI treatment of deposed objects is designed around this latter case (where combining into a single action isn't possible) rather than the "deposed only" situation (where it could potentially be).

This unusual situation isn't supposed to arise in normal use, but it can
come up in practice in some edge-case scenarios where Terraform fails in
a severe way during a create_before_destroy.

Some earlier versions of Terraform also had bugs in their handling of
deposed objects, so this may also arise if upgrading from one of those
older versions with some leftover deposed objects in the state.
@apparentlymart apparentlymart merged commit b1213f7 into master Jun 4, 2019
@apparentlymart apparentlymart deleted the b-plan-deposed-crash branch June 4, 2019 16:24
@ghost
Copy link

ghost commented Jul 25, 2019

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.

@ghost ghost locked and limited conversation to collaborators Jul 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

terraform 0.12 Crash running apply after upgrade
2 participants