Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

azurem_storage_account tries to recreate network_rules every plan #26854

Closed
1 task done
mtslzr opened this issue Jul 29, 2024 · 4 comments
Closed
1 task done

azurem_storage_account tries to recreate network_rules every plan #26854

mtslzr opened this issue Jul 29, 2024 · 4 comments

Comments

@mtslzr
Copy link
Contributor

mtslzr commented Jul 29, 2024

Is there an existing issue for this?

  • I have searched the existing issues

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 comments along the lines of "+1", "me too" or "any updates", 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 and review the contribution guide to help.

Terraform Version

1.9.1

AzureRM Provider Version

3.113.0

Affected Resource(s)/Data Source(s)

azurerm_storage_account

Terraform Configuration Files

resource "azurerm_storage_account" "storage" {
  name                     = "storage"
  resource_group_name      = azurerm_resource_group.storage.name
  location                 = azurerm_resource_group.storage.location
  account_tier             = "Standard"
  account_replication_type = "ZRS"

  enable_https_traffic_only = true
  min_tls_version           = "TLS1_2"
  
  network_rules {
    default_action = "Allow"
    bypass         = ["AzureServices"]
  }

  share_properties {
    retention_policy {
      days = 7
    }
  }
}

Debug Output/Panic Output

Example of an update-in-place:

  # azurerm_storage_account.storage["storage"] will be updated in-place
  ~ resource "azurerm_storage_account" "storage" {
        id                                 = "/subscriptions/12345/resourceGroups/storage/providers/Microsoft.Storage/storageAccounts/storage"
        name                               = "storage"
        tags                               = {}
        # (96 unchanged attributes hidden)

      + network_rules {
          + bypass                     = [
              + "AzureServices",
            ]
          + default_action             = "Allow"
          + ip_rules                   = (known after apply)
          + virtual_network_subnet_ids = (known after apply)
        }

        # (3 unchanged blocks hidden)
    }

Expected Behaviour

There should be no changes to the azurerm_storage_account

Actual Behaviour

Plans with no changes to azurerm_storage_account show it being updated-in-place with the network_rules (that already exist) being added. Applying the change does not change anything.

Steps to Reproduce

Create an azurerm_storage_account resource as above, apply it, then make an unrelated change in the same workspace.

Seems to have started after updating the provider to 3.113.0 (though not 100% on this).

Important Factoids

No response

References

No response

@magodo
Copy link
Collaborator

magodo commented Jul 30, 2024

@mtslzr The network_rules that you specified is its default setting, which has the same effect if just leave it absent. The document said:

If specifying network_rules, one of either ip_rules or virtual_network_subnet_ids must be specified and default_action must be set to Deny.

So please follow the document and remove the network_rules block.

@mtslzr
Copy link
Contributor Author

mtslzr commented Jul 30, 2024

Apologies. We haven't made any changes around network_rules in a long time, and it only started appearing in plans with the latest provider update, so I assumed something had changed. Removed and it is working as intended; sorry for the false alarm.

@mtslzr mtslzr closed this as completed Jul 30, 2024
@magodo
Copy link
Collaborator

magodo commented Jul 31, 2024

Hey @mtslzr, you are right, there do has a new changein the v3.113.0 that causes this issue. While as the behavior aligns with the document, so that is not caught by our test case, and also not regarded as an issue.

Anyway, thank you for reporting this 👍

Copy link

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants