Changing account_kind of azurerm_storage_account to StorageV2 causes destroy and create of storage account #5758

rosenkranzt · 2020-02-14T14:28:50Z

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v0.11.11
terraform-provider-azurerm_v1.40.0_x4

Affected Resource(s)

azurerm_storage_account

Terraform Configuration Files

resource "random_id" "storage_gen_name" {
  keepers = {
    project_id = "${var.landscape_name}"
  }

  byte_length = 12
}

resource "azurerm_storage_account" "storage" {
  # Storage account name must match 'a-z0-9'
  name = "storage${lower(replace(random_id.storage_gen_name.b64, "/[-_]/", ""))}"
  resource_group_name = "${var.azure_rg_name}"
  location = "${var.azure_region}"
  account_replication_type = "LRS"
  account_tier             = "Premium"
  account_kind = "StorageV2"
  enable_blob_encryption = true

  tags {
    Name = "cf-${var.landscape_name}"
  }
}

Debug Output

https://gist.github.com/rosenkranzt/b60b10be835be27f0c29e7dc19e79c8c

Panic Output

Expected Behavior

When changing argument account_kind of Terraform ressource azurerm_storage_account from account_kind Storage (general purpose v1) to StorageV2 I expect an upgrade of the storage account as offered in the Azure portal.

Actual Behavior

A storage account gets destroyed and recreated.
This behaviour is described in the documentation.

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

-/+ azurerm_storage_account.storage (new resource required)
      id:                                "/subscriptions/d3a8f57e-80fe-4ced-a1b1-c42b61584071/resourceGroups/rg-tr-03-od-azr/providers/Microsoft.Storage/storageAccounts/storagevtcipijbi0dlsnku" => <computed> (forces new resource)
      access_tier:                       "" => <computed>
      account_encryption_source:         "Microsoft.Storage" => "Microsoft.Storage"
      account_kind:                      "Storage" => "StorageV2" (forces new resource)
      account_replication_type:          "LRS" => "LRS"
      account_tier:                      "Standard" => "Standard"
      blob_properties.#:                 "1" => <computed>
      enable_advanced_threat_protection: "false" => <computed>
      enable_blob_encryption:            "true" => "true"
      enable_file_encryption:            "true" => "true"
      identity.#:                        "0" => <computed>
      is_hns_enabled:                    "false" => "false"
      location:                          "eastus2" => "eastus2"
      name:                              "storagevtcipijbi0dlsnku" => "storagevtcipijbi0dlsnku"
      network_rules.#:                   "1" => <computed>
      primary_access_key:                <sensitive> => <computed> (attribute changed)
      primary_blob_connection_string:    <sensitive> => <computed> (attribute changed)
      primary_blob_endpoint:             "https://storagevtcipijbi0dlsnku.blob.core.windows.net/" => <computed>
      primary_blob_host:                 "storagevtcipijbi0dlsnku.blob.core.windows.net" => <computed>
      primary_connection_string:         <sensitive> => <computed> (attribute changed)
      primary_dfs_endpoint:              "" => <computed>
      primary_dfs_host:                  "" => <computed>
      primary_file_endpoint:             "https://storagevtcipijbi0dlsnku.file.core.windows.net/" => <computed>
      primary_file_host:                 "storagevtcipijbi0dlsnku.file.core.windows.net" => <computed>
      primary_location:                  "eastus2" => <computed>
      primary_queue_endpoint:            "https://storagevtcipijbi0dlsnku.queue.core.windows.net/" => <computed>
      primary_queue_host:                "storagevtcipijbi0dlsnku.queue.core.windows.net" => <computed>
      primary_table_endpoint:            "https://storagevtcipijbi0dlsnku.table.core.windows.net/" => <computed>
      primary_table_host:                "storagevtcipijbi0dlsnku.table.core.windows.net" => <computed>
      primary_web_endpoint:              "" => <computed>
      primary_web_host:                  "" => <computed>
      queue_properties.#:                "1" => <computed>
      resource_group_name:               "rg-tr-03-od-azr" => "rg-tr-03-od-azr"
      secondary_access_key:              <sensitive> => <computed> (attribute changed)
      secondary_blob_connection_string:  <sensitive> => <computed> (attribute changed)
      secondary_blob_endpoint:           "" => <computed>
      secondary_blob_host:               "" => <computed>
      secondary_connection_string:       <sensitive> => <computed> (attribute changed)
      secondary_dfs_endpoint:            "" => <computed>
      secondary_dfs_host:                "" => <computed>
      secondary_file_endpoint:           "" => <computed>
      secondary_file_host:               "" => <computed>
      secondary_location:                "" => <computed>
      secondary_queue_endpoint:          "" => <computed>
      secondary_queue_host:              "" => <computed>
      secondary_table_endpoint:          "" => <computed>
      secondary_table_host:              "" => <computed>
      secondary_web_endpoint:            "" => <computed>
      secondary_web_host:                "" => <computed>
      tags.%:                            "1" => "1"
      tags.Name:                         "cf-tr-03-od-azr" => "cf-tr-03-od-azr"


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

Steps to Reproduce

Create a storage account of account_kind Storage.

resource "azurerm_storage_account" "storage" {
  # Storage account name must match 'a-z0-9'
  name = "storage${lower(replace(random_id.storage_gen_name.b64, "/[-_]/", ""))}"
  resource_group_name = "${var.azure_rg_name}"
  location = "${var.azure_region}"
  account_replication_type = "LRS"
  account_tier             = "Premium"
  account_kind = "Storage"
  enable_blob_encryption = true

  tags {
    Name = "cf-${var.landscape_name}"
  }
}

Then change argument account_kind StorageV2.

resource "azurerm_storage_account" "storage" {
  # Storage account name must match 'a-z0-9'
  name = "storage${lower(replace(random_id.storage_gen_name.b64, "/[-_]/", ""))}"
  resource_group_name = "${var.azure_rg_name}"
  location = "${var.azure_region}"
  account_replication_type = "LRS"
  account_tier             = "Premium"
  account_kind = "StorageV2"
  enable_blob_encryption = true

  tags {
    Name = "cf-${var.landscape_name}"
  }
}

Then run

terraform plan
terraform apply

Important Factoids

References

https://www.terraform.io/docs/providers/azurerm/r/storage_account.html

account_kind - (Optional) Defines the Kind of account. Valid options are BlobStorage, BlockBlobStorage, FileStorage, Storage and StorageV2. Changing this forces a new resource to be created. Defaults to Storage.

The text was updated successfully, but these errors were encountered:

Peter-Sternberger · 2020-02-14T14:35:03Z

👍

njuCZ · 2020-03-04T06:14:55Z

now In provider, we could only mark a resource should be updated or recreated when a field changes, there is no way to dynamically change the behavior(update or recreate)

MSSedusch · 2020-03-04T08:18:59Z

So it is not possible to look at which property changed and decide whether a resource need to be re-created or can be updated? For no Azure TF resource? Does that mean if I e.g. change tags for a TF resource, it will be re-created?

njuCZ · 2020-03-09T13:46:47Z

@MSSedusch Of course we can make resource update when a field changes. But in this case, if a user want to change the kind from "StorageV2" to "Storage", the update rest api will return error, thus result in another problem

MSSedusch · 2020-03-09T14:17:35Z

@njuCZ the idea is to change it from "Storage" to "StorageV2" which should be supported by the Azure Storage RP i.e. when you update from "Storage" to "StorageV2" using e.g. an ARM template, the update works and the data of the Storage Account is not removed.

tombuildsstuff · 2020-03-09T14:22:25Z

@MSSedusch to clarify here:

Whilst it's possible to move between some SKU's to some other SKU's (e.g. I believe Standard -> StandardV2 off the top of my head), moving between others (e.g Standard -> Premium) requires recreating the Storage Account.

Unfortunately with the way the Terraform Plugin SDK works today it's not possible to conditionally mark a field as ForceNew based on it's value (although that's planned) - as such for the moment we've opted to make this ForceNew, which will require recreation when this value changes.

However I think may want investigating/re-evaluating to instead return an error during the update here (prompting the user to taint the resource) if the account types aren't migrateable.

MSSedusch · 2020-03-09T14:26:44Z

@tombuildsstuff thanks for the clarification. I think I understood the problem now.

However I think may want investigating/re-evaluating to instead return an error during the update here (prompting the user to taint the resource) if the account types aren't migrateable.

That would work for us too :)

DoctorBizzle · 2020-03-20T11:20:18Z

Given that i don't want to trash my storagev1 accounts and their data to upgrade to v2, what is the terraform recommended way to achieve this upgrade?

e.g. do i have to remove the storagev1 accounts from tfstate, update them in Azure portal etc, import them back into tfstate, then terraform plan?

Having just had to do this for azurerm_recovery_services_protected_vm -> azurerm_backup_protected_vm and azurerm_recovery_services_protection_policy_vm -> azurerm_backup_policy_vm I'm somewhat frustrated at this point.

This sort of thing really ought to be in the AzureRM v1.x to v2.x upgrade guide.

ClaudiaBaur · 2020-03-31T11:37:26Z

Is there a roadmap for the way forward to migrate existing storage accounts from v1 to v2?

rem-aj · 2020-03-31T12:02:44Z

Workaround I use is upgrade manually in Portal and the then terraform will just do an update in place and add some extra properties to the state file once you apply it.

…

Sent from my mobile device

On Tue, Mar 31, 2020, 7:37 AM Claudia Baur ***@***.***> wrote: Is there a roadmap for the way forward to migrate existing storage accounts from v1 to v2? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5758 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKK5KVB6GWULQTZB6JDK7LRKHIYLANCNFSM4KVJF7FQ> .

ClaudiaBaur · 2020-05-13T11:44:08Z

@tombuildsstuff, we cannot upgrade manually as we have a bunch of landscapes running using older storage accounts which are distributed through the company. Please have a look at #6580 which was provided by Tobias. Thanks!

* Add resource migration for Storage Account * Update docs to show new behavior * Update config name to indicate it's a prepare step Co-authored-by: Jeffrey Cline <20408400+WodansSon@users.noreply.github.com>

ghost · 2020-05-15T00:31:13Z

This has been released in version 2.10.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 2.10.0"
}
# ... other configuration ...

ghost · 2020-06-13T14:50:48Z

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!

tracypholmes added bug service/storage labels Feb 21, 2020

HappyTobi mentioned this issue Apr 22, 2020

azurerm_storage_account - Enable migration of account_kind from Storage to StorageV2 #6580

Merged

WodansSon added this to the v2.10.0 milestone May 13, 2020

WodansSon added the documentation label May 13, 2020

WodansSon closed this as completed in #6580 May 14, 2020

WodansSon added a commit that referenced this issue May 14, 2020

fixes #5758

02c1024

* Add resource migration for Storage Account * Update docs to show new behavior * Update config name to indicate it's a prepare step Co-authored-by: Jeffrey Cline <20408400+WodansSon@users.noreply.github.com>

hashicorp locked and limited conversation to collaborators Jun 13, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Changing account_kind of azurerm_storage_account to StorageV2 causes destroy and create of storage account #5758

Changing account_kind of azurerm_storage_account to StorageV2 causes destroy and create of storage account #5758

rosenkranzt commented Feb 14, 2020

Peter-Sternberger commented Feb 14, 2020

njuCZ commented Mar 4, 2020

MSSedusch commented Mar 4, 2020

njuCZ commented Mar 9, 2020

MSSedusch commented Mar 9, 2020

tombuildsstuff commented Mar 9, 2020

MSSedusch commented Mar 9, 2020 •

edited

DoctorBizzle commented Mar 20, 2020 •

edited

ClaudiaBaur commented Mar 31, 2020

rem-aj commented Mar 31, 2020 via email

ClaudiaBaur commented May 13, 2020 •

edited

ghost commented May 15, 2020

ghost commented Jun 13, 2020

Changing account_kind of azurerm_storage_account to StorageV2 causes destroy and create of storage account #5758

Changing account_kind of azurerm_storage_account to StorageV2 causes destroy and create of storage account #5758

Comments

rosenkranzt commented Feb 14, 2020

Community Note

Terraform (and AzureRM Provider) Version

Affected Resource(s)

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

References

Peter-Sternberger commented Feb 14, 2020

njuCZ commented Mar 4, 2020

MSSedusch commented Mar 4, 2020

njuCZ commented Mar 9, 2020

MSSedusch commented Mar 9, 2020

tombuildsstuff commented Mar 9, 2020

MSSedusch commented Mar 9, 2020 • edited

DoctorBizzle commented Mar 20, 2020 • edited

ClaudiaBaur commented Mar 31, 2020

rem-aj commented Mar 31, 2020 via email

ClaudiaBaur commented May 13, 2020 • edited

ghost commented May 15, 2020

ghost commented Jun 13, 2020

MSSedusch commented Mar 9, 2020 •

edited

DoctorBizzle commented Mar 20, 2020 •

edited

ClaudiaBaur commented May 13, 2020 •

edited