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

provider/azurerm: Terraform Plan errors when created resources disappear #8859

Merged
merged 2 commits into from
Oct 6, 2016

Conversation

carinadigital
Copy link
Contributor

@carinadigital carinadigital commented Sep 15, 2016

Terraform can't plan correctly when a VM is manually removed from Azure. The vmClient() API call returns an error for 404 return. This is different to subnetClient() which doesn't error for 404 returns. subnetClient() also errors the same way. This may be a consistent problem across the provider.

To Reproduce:

  1. Apply a plan to create a VM (example is below)
  2. Manually delete a VM
  3. Try to Plan. Terraform shows the following error
Error refreshing state: 1 error(s) occurred:

* azurerm_virtual_machine.test: Error making Read request on Azure Virtual Machine acctvm: compute.VirtualMachinesClient#Get: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="ResourceNotFound" Message="The Resource 'Microsoft.Compute/virtualMachines/acctvm' under resource group 'acctestrg' was not found."

Terraform HCL

resource "azurerm_resource_group" "test" {
    name = "acctestrg"
    location = "West US"
}

resource "azurerm_virtual_network" "test" {
    name = "acctvn"
    address_space = ["10.0.0.0/16"]
    location = "West US"
    resource_group_name = "${azurerm_resource_group.test.name}"
}

resource "azurerm_subnet" "test" {
    name = "acctsub"
    resource_group_name = "${azurerm_resource_group.test.name}"
    virtual_network_name = "${azurerm_virtual_network.test.name}"
    address_prefix = "10.0.2.0/24"
}

resource "azurerm_network_interface" "test" {
    name = "acctni"
    location = "West US"
    resource_group_name = "${azurerm_resource_group.test.name}"

    ip_configuration {
        name = "testconfiguration1"
        subnet_id = "${azurerm_subnet.test.id}"
        private_ip_address_allocation = "dynamic"
    }
}

resource "azurerm_storage_account" "test" {
    name = "accsa"
    resource_group_name = "${azurerm_resource_group.test.name}"
    location = "westus"
    account_type = "Standard_LRS"

    tags {
        environment = "staging"
    }
}

resource "azurerm_storage_container" "test" {
    name = "vhds"
    resource_group_name = "${azurerm_resource_group.test.name}"
    storage_account_name = "${azurerm_storage_account.test.name}"
    container_access_type = "private"
}

resource "azurerm_virtual_machine" "test" {
    name = "acctvm"
    location = "West US"
    resource_group_name = "${azurerm_resource_group.test.name}"
    network_interface_ids = ["${azurerm_network_interface.test.id}"]
    vm_size = "Standard_A0"

    storage_image_reference {
        publisher = "Canonical"
        offer = "UbuntuServer"
        sku = "14.04.2-LTS"
        version = "latest"
    }

    storage_os_disk {
        name = "myosdisk1"
        vhd_uri = "${azurerm_storage_account.test.primary_blob_endpoint}${azurerm_storage_container.test.name}/myosdisk1.vhd"
        caching = "ReadWrite"
        create_option = "FromImage"
    }

    os_profile {
        computer_name = "hostname"
        admin_username = "testadmin"
        admin_password = "Password1234!"
    }

    os_profile_linux_config {
        disable_password_authentication = false
    }

    tags {
        environment = "staging"
    }
}

@carinadigital
Copy link
Contributor Author

I think these errors were introduced in #8607

@carinadigital
Copy link
Contributor Author

It looks like #8607 introduced a bug into all the azurerm resources, which now prevents refreshing resources that are deleted/not present. This will need some additional work.

@carinadigital carinadigital changed the title Fix AzureRM behaviour with missing vm. [WIP] provider/azurerm: Terraform Plan errors when reading missing resources Sep 29, 2016
@carinadigital
Copy link
Contributor Author

carinadigital commented Sep 29, 2016

Adding some acceptance tests that show the problem.
The fixes are simple, but all the azurerm resources are missing this type of test.

@carinadigital carinadigital force-pushed the arm-vm-fix branch 3 times, most recently from ad3f2f1 to dbc94ae Compare September 30, 2016 16:17
Andreas Kyrris added 2 commits October 3, 2016 10:10
Regressions were introduced when fixing
hashicorp#8607 . Specifically when
resources in the statefile are deleted or missing in real life, then
terraform plan would exit with an error when it recieved a 404 not
found. The correct behaviour would be to show a plan with the offer to
create the missing resources.
@carinadigital
Copy link
Contributor Author

This is now ready for review.
Tests have been added named as '_disappears' if you want to run a subset of the acceptance tests.

@carinadigital carinadigital changed the title [WIP] provider/azurerm: Terraform Plan errors when reading missing resources provider/azurerm: Terraform Plan errors when created resources disappear Oct 3, 2016
@stack72
Copy link
Contributor

stack72 commented Oct 6, 2016

Hi @carinadigital

This LGTM! Thanks for the work here :) Ran a set of the tests and all look good!

=== RUN   TestAccAzureRMAvailabilitySet_disappears
--- PASS: TestAccAzureRMAvailabilitySet_disappears (88.45s)
=== RUN   TestAccAzureRMCdnEndpoint_disappears
--- PASS: TestAccAzureRMCdnEndpoint_disappears (229.48s)
=== RUN   TestAccAzureRMLocalNetworkGateway_disappears
--- PASS: TestAccAzureRMLocalNetworkGateway_disappears (126.87s)
=== RUN   TestAccAzureRMNetworkInterface_disappears
--- PASS: TestAccAzureRMNetworkInterface_disappears (180.21s)
=== RUN   TestAccAzureRMNetworkSecurityGroup_disappears
--- PASS: TestAccAzureRMNetworkSecurityGroup_disappears (127.10s)

@ghost
Copy link

ghost commented Apr 21, 2020

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 Apr 21, 2020
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.

3 participants