azure.storage.Account marked as replace when upgrading from provider v4 to v5
#2134
Comments
ringods
added
kind/bug
|
A similar issue was also observed upstream: hashicorp/terraform-provider-azurerm#14279 This is less of an issue in the upstream use because the default behaviour is to use the new version of the provider to perform a refresh before any next operation. Pulumi does not perform a refresh by default and when performing a refresh it will use the previous version of the provider (this is stored in the state) rather than the version in the program. Related issue: There's also the issue of the oddity of the diff reporting changes even though the changes show as identical - this needs further investigation to understand why it is being reported like this. WorkaroundThe two options to work around the issue right now:
Option 1 is likely to be less steps overall as your code would not need to be edited:
Option 2 avoids direct edits, but is a little more long-winded and will be tricky if other resources depend on it:
|
|
Thanks for the options. I checked my state and it doesn't already contain the 5.x provider, so can you confirm that what I'm doing is appropriate? My plan is:
My thinking here is that it's better for me to only script changing the resource that is having an issue rather than making large changes to the state. I'd like to have something generic I can document for other teams to use so I'm trying to minimize the chances of other side effects. |
|
Hello @gpduck and others bumping into this issue, We have a shorter and less intrusive way of patching the stack state. Here are the verified steps to upgrade, starting from a stack using a Pulumi Azure v4:
Pulumi should no longer say the storage accounts will be replaced, but |
|
Had another look here and there's a few issues going on. Firstly the diff displayed in the original issue is plain wrong. The properties shown to change from the same value are not actually present in the state, so can't have that value. This bit is fixed by enrolling the resource into a bridge feature called PlanResourceChange: #2150 Unfortunately that does not fix the replace but the diff is actually sensible but still not 100% obvious. The resource is replaced due to which is visible from the GRPC call: "detailedDiff": {
"allowNestedItemsToBePublic": {},
"crossTenantReplicationEnabled": {},
"defaultToOauthAuthentication": {},
"dnsEndpointType": {
"kind": "ADD_REPLACE"
},
"localUserEnabled": {},
"publicNetworkAccessEnabled": {},
"sftpEnabled": {}
},The CLI output here can be improved but that looks like something on the engine side perhaps? However this now reproes in Terraform too: provider "azurerm" {
features {}
version = "2.99.0" // change to 3.109.0
}
resource "azurerm_resource_group" "resourceGroup" {
name = "resourceGroup"
location = "westeurope"
}
resource "azurerm_storage_account" "ducktest12" {
name = "ducktest12"
resource_group_name = azurerm_resource_group.resourceGroup.name
location = "westeurope"
account_tier = "Standard"
account_kind = "StorageV2"
account_replication_type = "LRS"
access_tier = "Hot"
enable_https_traffic_only = true
min_tls_version = "TLS1_2"
network_rules {
default_action = "Deny"
virtual_network_subnet_ids = []
ip_rules = []
}
}yields the same replace after upgrading However, running with refresh Unfortunately the refresh does not fix the issue on the pulumi side. However a workaround under PRC is to use |
Fixes the replace in #2134 by enrolling storage:account into PRC. This produces the correct diff. This PR also adds a state transform for the dnsEndpointType which forces a replace both on the pulumi and on the TF side. discussed in #2134 (comment) fixes #2134
|
This issue has been addressed in PR #2150 and shipped in release v5.82.0. |
Describe what happened
Customer reports that Pulumi wants to replace their existing
azure.storage.Accountresource after upgrading the provider from major v4 to major v5.To reproduce, first run the sample program with v4.42.0 of this provider as defined in the
package.json. After succesful creation of the storage account, upgrade to@pulumi/azure@v5.0.0or later. I tried both v5.0.0 and the v5.80.0, the latest at the time of writing.When using v5.0.0, I also tried going back in time with the Pulumi CLI/engine and tested with Pulumi v3.30.0, which is from around the time of v4.42.0 and v5.0.0 of this provider.
https://github.com/pulumi/pulumi-azure/releases/tag/v4.42.0
https://github.com/pulumi/pulumi-azure/releases/tag/v5.0.0
https://github.com/pulumi/pulumi/releases/tag/v3.30.0
Also with Pulumi v3.30.0, I got the replace of the storage account reported.
Sample program
index.ts
package.json
{ "name": "5389", "main": "index.ts", "devDependencies": { "@types/node": "^18", "typescript": "^5.0.0" }, "dependencies": { "@pulumi/azure": "4.42.0", "@pulumi/pulumi": "^3.113.0" } }Log output
From v4.42.0 to v5.0.0
From v4.42.0 to v5.80.0
Affected Resource(s)
azure.storage.Account
Output of
pulumi aboutAdditional context
No response
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: