hashicorp / terraform-provider-azurerm

Terraform provider for Azure Resource Manager
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs
Mozilla Public License 2.0
4.52k stars 4.6k forks source link

State migration to 4.0 fails to unmarshall `azurerm_cosmosdb_account.ip_range_filter` field #27192

Closed AndreiBarbuOz closed 1 week ago

AndreiBarbuOz commented 2 weeks ago

Is there an existing issue for this?

Community Note

Terraform Version

1.9.5

AzureRM Provider Version

4.0.1

Affected Resource(s)/Data Source(s)

azurerm_cosmosdb_account

Terraform Configuration Files

resource "azurerm_cosmosdb_account" "hello_world" {
  name                = var.cosmosdb_account_name
  location            = var.location
  resource_group_name = var.resource_group_name
  offer_type          = "Standard"
  kind                = "GlobalDocumentDB"
  capabilities {
    name = "EnableServerless"
  }

  consistency_policy {
    consistency_level = "Session"
  }

  geo_location {
    location          = var.location
    failover_priority = 0
  }

  public_network_access_enabled = true
  ip_range_filter               = "0.0.0.0"
}

followed by an upgrade of the provider


### Debug Output/Panic Output

```shell
N/A

Expected Behaviour

Expected the field to be successfully migrated

Actual Behaviour

│ Error: missing expected [
│
│
╵
╷
│ Error: missing expected [
│
│   with azurerm_cosmosdb_account.hello_world,
│   on main.tf line 318, in resource "azurerm_cosmosdb_account" "hello_world":
│  318: resource "azurerm_cosmosdb_account" "hello_world" {

Steps to Reproduce

No response

Important Factoids

No response

References

No response

oraum commented 2 weeks ago

I'm seeing a somewhat similar error when trying to migrate from 3.116.0 to 4.0.1:

Error decoding "azurerm_cosmosdb_account.hello_world" from prior state:
unsupported attribute "connection_strings"

Error: missing expected [
...

As the connection_strings property was dropped according to changelog - I would expect the provider to migrate/drop the field automatically from state or otherwise a note in changelog on how to remove the property manually

stephybun commented 2 weeks ago

@oraum the Error decoding message you're seeing there is misleading, the issue is that the state isn't able to read the ip_range_filter property which is still in a string format.

The underlying type for the field ip_range_filter changed from a string to a set in v4.0, which means the resource needs to be removed from state, the ip_range_filter argument updated to a set, then the resource can be imported.

oraum commented 2 weeks ago

@stephybun thanks for the notice, removing the cosmos db from state and re-importing it did indeed solve the issue for me.

achistef commented 2 weeks ago

+1. We're facing the missing expected [ and unsupported attribute "connection_strings" errors when migrating our IAC to v4. Will there be a solution that does not involve re-importing everything to the state?

sbx0r commented 2 weeks ago

+1. We're facing the missing expected [ and unsupported attribute "connection_strings" errors when migrating our IAC to v4. Will there be a solution that does not involve re-importing everything to the state?

Same error. Same question.

pacorreia commented 2 weeks ago

Same happens due to the partition_key_path.

Also when I do a dump from the state file using version 4.x.x, no cosmosdb entries there, 0, nothing, gone... I just get warnings on failing to decode CosmosDb resource properties because of presence of an unknown one.

Before version 4.x.x, there were a couple of deprecated properties that I've removed and started using the one's, but seems the state file was not properly "cleaned" up and now we've garbage conflicting with the new version that no longer recognizes.

dimiter-todorov-georgiev commented 2 weeks ago

I am facing a similar issue, upgrading from azurerm 3.116.0 to 4.0.1. The connection_strings property cannot be imported from the previous state, and I get a cryptic "missing [" error. I don't have ip_filter_range in my configs. I've been able to stabilize the situation by rolling back to 3.116.0. Waiting for this issue to be resolved before I attempt another upgrade.

Benj13 commented 2 weeks ago

I tried the removing and re-importing the resource from the state and that did the trick. Not ideal but at least I was able to deploy using 4.0.1

pacorreia commented 2 weeks ago

I tried the removing and re-importing the resource from the state and that did the trick. Not ideal but at least I was able to deploy using 4.0.1

yep that does the trick as it will effective remove all entres, but not the desired solution, but does help further testing the new version