azurerm_cosmosdb_account replacement forced in redeploy cases because of the create_mode attribute

[jlodiba]

Is there an existing issue for this?

• [X] I have searched the existing issues

Community Note

• Please vote on this issue by adding a :thumbsup: 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 Version

1.1.9

AzureRM Provider Version

3.59.0

Affected Resource(s)/Data Source(s)

azurerm_cosmosdb_account

Terraform Configuration Files

resource "azurerm_cosmosdb_account" "main" {
  name                              = "cdbnametst1"
  location                          = "westeurope"
  resource_group_name               = "cdbrsgnametst1"
  offer_type                        = "Standard"
  create_mode                       = "Default"
  kind                              = "GlobalDocumentDB"
  is_virtual_network_filter_enabled = false
  public_network_access_enabled     = false

  identity {
    type = "SystemAssigned"
  }

  backup {
    type = "Continuous"
  }

  capabilities {
    name = "EnableTable"
  }

  consistency_policy {
    consistency_level = "Eventual"
  }

  geo_location {
    location          = "westeurope"
    failover_priority = 0
    zone_redundant    = true
  }
}

Debug Output/Panic Output

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # azurerm_cosmosdb_account.main must be replaced
-/+ resource "azurerm_cosmosdb_account" "main" {
      ~ connection_strings                       = (sensitive value)
      + create_mode                              = "Default" # forces replacement
      ~ endpoint                                 = "https://cdbnametst1.documents.azure.com:443/" -> (known after apply)
      ~ id                                       = "/subscriptions/<az_subscription_id>/resourceGroups/cdbrsgnametst1/providers/Microsoft.DocumentDB/databaseAccounts/cdbnametst1" -> (known after apply)
      + mongo_server_version                     = (known after apply)
        name                                     = "cdbnametst1"
      - network_acl_bypass_ids                   = [] -> null
      ~ primary_key                              = (sensitive value)
      ~ primary_readonly_key                     = (sensitive value)
      ~ primary_readonly_sql_connection_string   = (sensitive value)
      ~ primary_sql_connection_string            = (sensitive value)
      ~ read_endpoints                           = [
          - "https://cdbnametst1-westeurope.documents.azure.com:443/",
        ] -> (known after apply)
      ~ secondary_key                            = (sensitive value)
      ~ secondary_readonly_key                   = (sensitive value)
      ~ secondary_readonly_sql_connection_string = (sensitive value)
      ~ secondary_sql_connection_string          = (sensitive value)
      - tags                                     = {} -> null
      ~ write_endpoints                          = [
          - "https://cdbnametst1-westeurope.documents.azure.com:443/",
        ] -> (known after apply)
        # (14 unchanged attributes hidden)

      ~ analytical_storage {
          ~ schema_type = "WellDefined" -> (known after apply)
        }

      ~ backup {
          ~ interval_in_minutes = 0 -> (known after apply)
          ~ retention_in_hours  = 0 -> (known after apply)
          + storage_redundancy  = (known after apply)
            # (1 unchanged attribute hidden)
        }

      + capacity {
          + total_throughput_limit = (known after apply)
        }

      ~ consistency_policy {
          ~ max_interval_in_seconds = 5 -> (known after apply)
          ~ max_staleness_prefix    = 100 -> (known after apply)
            # (1 unchanged attribute hidden)
        }

      - geo_location {
          - failover_priority = 0 -> null
          - id                = "cdbnametst1-westeurope" -> null
          - location          = "westeurope" -> null
          - zone_redundant    = true -> null
        }
      + geo_location {
          + failover_priority = 0
          + id                = (known after apply)
          + location          = "westeurope"
          + zone_redundant    = true
        }

      ~ identity {
          - identity_ids = [] -> null
          ~ principal_id = "<az_principal_id>" -> (known after apply)
          ~ tenant_id    = "<az_tenant_id>" -> (known after apply)
            # (1 unchanged attribute hidden)
        }
        # (1 unchanged block hidden)
    }

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

Expected Behaviour

The Terraform configuration shoud be idempotent, in other words no matter how many times a plan is launched with the configuration above there shoudn't be any changes.

Actual Behaviour

When a create_mode value is specified and a capability is going to be used then when an cosmosdb account is already deployed when launching a plan and/or apply then the provider tells that a resource replacement is needed.

Notes:

• The value of the create_mode attribute in the tfstate file appears as "" when the apply finishes. This is strange because if we don't use both the create_mode and the capabilities arguments then the create_mode in the tfstate file would end up with "Default" value while the capabilities one with an emptly list.
• When debugging the plan of the redeploy the resource JSON, obtained with the GET API operation, does not return the createMode value.
• This issue applies to any create_mode value (Default or Restore).
• This behaviour does not happen when there is no capability specified in the configuration.
• The API version of the provider used to obtain the information of the account in the plan is "2021-10-15".

Steps to Reproduce

1. terraform init
2. terraform apply
3. terraform plan/apply

Important Factoids

• The error appears to have something to do with the API version. The API version the provider uses to return the resource information is "2021-10-15" (GET /subscriptions//resourceGroups/cdbrsgnametst1/providers/Microsoft.DocumentDB/databaseAccounts/cdbnametst1?api-version=2021-10-15), and that one does not return the createMode. From the API 2022-11-15 version the createMode apparently is returned.
• Is when the service has any capability enabled that the API omites the createMode argument.

References

No response

[neil-yechenwei]

Thanks for raising this issue. Seems it's service API issue since CosmosDB.Account GET API doesn't return createMode anymore when capabilities is set. So filed an issue https://github.com/Azure/azure-rest-api-specs/issues/24378 for tracking.