[v0.10.0] azurerm_image permanent recreation bug

[DonEstefan]

Terraform Version

Terraform v0.10.0
terraform-provider-azurerm_v0.1.4_x4

Affected Resource(s)

azurerm_image

Terraform Configuration Files

resource "azurerm_image" "new-managed-image" {
  name                  = "my-new-managed-image.vhd"
  location              = "${azurerm_resource_group.some-rg.location}"
  resource_group_name   = "${azurerm_resource_group.some-rg.name}"
  os_disk {
    os_type  = "Linux"
    os_state = "Generalized"
    blob_uri = "https://somestoreaccount.blob.core.windows.net/some-storage-container/some-linux.vhd"
  }
}

Expected Behavior

image is created on first "terrafrom apply"
image will be deleted and recreated when "blob_uri" changes and "terraform apply" is run again
image will not be deleted when blob_uri is unchanged and "terraform apply" is run again

Actual Behavior

image is deleted and recreated in every "terraform apply" run - even if blob_uri is unchanged

Steps to Reproduce

1. create a config like shown above
2. terraform apply (image will be created)
3. terraform plan (shows unnecessary recreation)

$ terraform plan
-/+ azurerm_image.new-managed-image (new resource required)
....
      os_disk.9999999999.blob_uri:        "" => "https://somestoreaccount.blob.core.windows.net/some-storage-container/some-linux.vhd" (forces new resource)
....

[DonEstefan]

Currently I'm using ignore_changes to work around the problem.

resource "azurerm_image" "new-managed-image" {
.....
  os_disk {
    ...
    blob_uri =
  }
  lifecycle {
    ignore_changes = ["os_disk"]
  }
}

Funny enough, the changes to os_disk will not be ignored completely afterwards.
Changing the blob_uri in the os_disk block will still cause the image to be deleted and recreated.
While i find this behaviour quite confusing - it luckily makes everything work just as i would expected it to work. The image is only recreated when blob_uri was changed.

[echuvyrov]

hey @DonEstefan I am trying to recreate the scenario above and not having much luck. I pasted my full config file below the output I am seeing - can you paste a small repro config for me to investigate further?

azurerm_image.testdestination: Still creating... (10s elapsed)
azurerm_image.testdestination: Still creating... (20s elapsed)
azurerm_image.testdestination: Still creating... (30s elapsed)
azurerm_image.testdestination: Still creating... (40s elapsed)
azurerm_image.testdestination: Still creating... (50s elapsed)
azurerm_image.testdestination: Still creating... (1m0s elapsed)
azurerm_image.testdestination: Creation complete (ID: /subscriptions/xxxx-xxxx-xxxx...ders/Microsoft.Compute/images/accteste)

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

**TEDs-MacBook-Pro:imgnew ted$ terraform plan**

Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

azurerm_resource_group.test: Refreshing state... (ID: /subscriptions/xxxx-xxxx-xxxx/resourceGroups/acctestRG-testimg)
azurerm_image.testdestination: Refreshing state... (ID: /subscriptions/xxxx-xxxx-xxxx-...ders/Microsoft.Compute/images/accteste)
**No changes. Infrastructure is up-to-date.**

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, Terraform
doesn't need to do anything.

**TEDs-MacBook-Pro:imgnew ted$ terraform apply**

azurerm_resource_group.test: Refreshing state... (ID: /subscriptions/xxxx-xxxx-xxxx/resourceGroups/acctestRG-testimg)
azurerm_image.testdestination: Refreshing state... (ID: /subscriptions/xxxx-xxxx-xxxx-...ders/Microsoft.Compute/images/accteste)

**Apply complete! Resources: 0 added, 0 changed, 0 destroyed.**

My main.tf file

resource "azurerm_resource_group" "test" {
  name     = "acctestRG-testimg"
  location = "westcentralus"
}

resource "azurerm_image" "testdestination" {
  name                = "accteste"
  location            = "${azurerm_resource_group.test.location}"
  resource_group_name = "${azurerm_resource_group.test.name}"

  os_disk {
    os_type  = "Linux"
    os_state = "Generalized"
    blob_uri = "https://terraformdev.blob.core.windows.net/packerimages/ubuntu_plain.vhd"
    size_gb  = 30
    caching  = "None"
  }

  tags {
    environment = "Dev"
    cost-center = "Ops"
  }
}

[DonEstefan]

Hi @echuvyrov,
here ist what I do:

resource "azurerm_resource_group" "test-rg" {
        name            = "test-rg"
        location        = "westeurope"
}

resource "azurerm_storage_account" "test-store-account" {
  name                = "teststoreaccount"
  resource_group_name = "${azurerm_resource_group.test-rg.name}"
  location            = "${azurerm_resource_group.test-rg.location}"
  account_type        = "Standard_LRS"
}

resource "azurerm_storage_container" "test-storage-container" {
  name                  = "test-storage-container"
  resource_group_name   = "${azurerm_resource_group.test-rg.name}"
  storage_account_name  = "${azurerm_storage_account.test-store-account.name}"
  container_access_type = "private"
}

#get a copy from the linux disk template we use
resource "azurerm_storage_blob" "local-disk-copy" {
  name = "local-disk-copy"
  resource_group_name    = "${azurerm_resource_group.test-rg.name}"
  storage_account_name   = "${azurerm_storage_account.test-store-account.name}"
  storage_container_name = "${azurerm_storage_container.test-storage-container.name}"
  source_uri             = "<some-azure-SAS-url>"
}

#create an managed image from the disk template we just copied
resource "azurerm_image" "managed-image-from-local-disk-copy" {
  name                   = "managed-image.vhd"
  location               = "${azurerm_resource_group.test-rg.location}"
  resource_group_name    = "${azurerm_resource_group.test-rg.name}"
  os_disk {
    os_type = "Linux"
    os_state = "Generalized"
    blob_uri = "${azurerm_storage_blob.local-disk-copy.url}"
  }
##use this to work around the permanent recreation bug
#  lifecycle {
#    ignore_changes = ["os_disk"]
#  }
}

so every time i run "terraform plan" I get

-/+ azurerm_image.managed-image-from-local-disk-copy (new resource required)
      location:                           "westeurope" => "westeurope"
      name:                               "managed-image.vhd" => "managed-image.vhd"
      os_disk.#:                          "1" => "1"
      os_disk.1679696862.os_state:        "Generalized" => ""
      os_disk.1679696862.os_type:         "Linux" => ""
      os_disk.4250202739.blob_uri:        "" => "https://teststoreaccount.blob.core.windows.net/test-storage-container/local-disk-copy.vhd" (forces new resource)
      os_disk.4250202739.managed_disk_id: "" => "<computed>"
      os_disk.4250202739.os_state:        "" => "Generalized"
      os_disk.4250202739.os_type:         "" => "Linux"
      os_disk.4250202739.size_gb:         "" => "<computed>"
      resource_group_name:                "test-rg" => "test-rg"
      tags.%:                             "0" => "<computed>"


Plan: 1 to add, 0 to change, 1 to destroy.

[jake-delorme]

I am having the same issue. VMS built referncing this image are also destroyed and recreated every run when it detects the blob_uri as "changed".

resource "azurerm_image" "centos7" {
  name                = "centos7"
  location            = "East US 2"
  resource_group_name = "rs-dev"

  os_disk {
    os_type  = "Linux"
    os_state = "Generalized"
    blob_uri = "https://<redacted>.blob.core.windows.net/centos/centos7.vhd"
  }
}

resource "azurerm_virtual_machine" "InternetGW" {
....
storage_image_reference {
    id = "${azurerm_image.centos7.id}"
  }

  storage_os_disk {
    name              = "InternetGW-OS"
    caching           = "ReadWrite"
    create_option     = "FromImage"
    managed_disk_type = "Standard_LRS"
  }
....
}

Running plan after a sucesfull run with no changes produces the following"

-/+ azurerm_virtual_machine.InternetGW (new resource required)
...
storage_image_reference.4128279647.id:                              "/subscriptions/<redacted>/resourceGroups/rs-dev/providers/Microsoft.Compute/images/centos7" => "" (forces new resource)

-/+ azurerm_image.centos7 (new resource required)
      os_disk.2572500909.blob_uri:        "" => "https://<redacted>.blob.core.windows.net/centos/centos7.vhd" (forces new resource)

[echuvyrov]

Hey @jake-delorme @DonEstefan I think I finally figured out what's going here. My sample HCL included the "caching" parameter in the "os_disk" section of the "azurerm_image" whereas yours didn't. When I removed that parameter I got the same behavior (image recreation on every run) that you reported. I submitted a PR (above) to fix that. In the meantime, you can work around the issue by specifying that param in your script (assuming my findings are correct of course :)).

Let me know how it goes!

[DonEstefan]

Hey @echuvyrov,
i can confirm, that the problem is gone when using caching = "None"
You seem to be on the right track. Thanks for your help!

[tombuildsstuff]

Hey @DonEstefan

Glad to hear that's working for you now. I've merged @echuvyrov's PR #259 which includes a fix for this - and should go out in the next release; as such I'm going to close this issue, but please feel free to re-open this if there's still an issue here :)

Thanks!

[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. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!