Change json state

Terraform Providers Azure
1

For some Azure storage accounts, during import, I spotted similar behaviour described here:

Basically, transform import is not able to read cross_tenant_replication_enabled property (the old one created around 2020) and in state json file I got:

cross_tenant_replication_enabled = null

Obviously, in terraform plan I got:

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # module.AzureStorage.azurerm_storage_account.account["name"] will be updated in-place
  ~ resource "azurerm_storage_account" "account" {
      + cross_tenant_replication_enabled  = true
        id                                = "/subscriptions/***/resourceGroups/**/providers/Microsoft.Storage/storageAccounts/name"
        name                              = "name"
        tags                              = {}
        # (37 unchanged attributes hidden)

      - timeouts {}

        # (4 unchanged blocks hidden)
    }

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

I know, this is a bug (or issue with old SDK) but how to mitigate it?
I would like to get No changes in terraform plan output.
After manual change in state json file null → true (for cross_tenant_replication_enabled) I got right output. But I don’t thing that manipulating state manually/by script is a good approach?
Maybe there is a trick during the import stage?
Thanks for any ideas/suggestions

2

Hi @Marian,

In this particular situation I expect I would let Terraform apply this plan, which would presumably cause the Azure provider to make a redundant update to this object (setting it to the value it already had) but then updating the state to match itself. Unless making that redundant update is harmful for some reason, you can often just let things converge as normal after an import.

Where things get tricky is in situations where the argument that the provider cannot import is also one that can’t be changed without replacing the object. In that case it is of course more bothersome to endure the object being replaced just to get Terraform’s state resynchronized, and so that is a situation where a manual state update is sometimes the best approach.

1 Like
3

Thx @apparentlymart for answer. This gives me the bigger picture. The terraform import and terraform plan is a part of pipeline where I have to make some decision base on output. The most challenging part here , as a see it, will be parse output of the plan cause here we have few cases:

High level flow:

  1. Update in place - Not updated value in state but is present in conf/azure
    I can leave is as is
    How to parse?
    ‘~ update in-place’ in the output
    ‘+’ letf to <already_covered_param>

  2. Update in place - Not present value in conf (not covered by tf conf - some edge attr) and tf need to want to sent it
    I should update tf conf first
    How to parse?
    ‘~ update in-place’ in the output
    ‘+’ letf to <not_covered_param>

  3. Force replacement - Not updated value in state but is present in conf/azure
    Update manually state
    How to parse?
    ‘replaced’ in the output - of maybe more specific
    ‘+’ letf to <already_covered_param>

  4. Force replacement - Not present value in conf (not covered by tf conf - some edge attr) and tf need to want to sent it
    I should update tf conf first
    ‘replaced’ in the output - of maybe more specific
    ‘+’ letf to <not_covered_param>

  5. Other error
    I should update tf conf first (most probably)
    How to parse?
    -detailed-exitcode 2

Is that make sense?