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
Changing public_network_access_enabled should not force replacement #21014
Comments
Hi @epomatti , thanks for raising this issue. I will raise PR to fix this soon. |
Hi @epomatti , in current 2022-01-01 API version of batch used in Azurerm Provider, changing this property will not be effected hence this property is labeled forceNew. Which means that no matter what you feed into the API after the initial setting, it will not be changed even you ask it to change specificly. Here is the evidence:
|
This issue has been fixed in later API version and we will work on upgrading the API version. Once that is done, we will remove the forceNew label here. But if you really need this now. I would recommend you to use AzAPI provider. Here is an example. Be sure to use
|
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. |
Is there an existing issue for this?
Community Note
Terraform Version
1.4.2
AzureRM Provider Version
3.48.0
Affected Resource(s)/Data Source(s)
azurerm_batch_account
Terraform Configuration Files
Debug Output/Panic Output
Expected Behaviour
Changing
public_network_access_enabled
value on aazurerm_batch_account
should be an update on the resource, not a replacement.Actual Behaviour
When I change
public_network_access_enabled
value on aazurerm_batch_account
resource, it forces replacement of the Batch account.Steps to Reproduce
public_network_access_enabled
The plan will have an action to replace the batch account, but it should only be updated.
Important Factoids
No response
References
https://learn.microsoft.com/en-us/azure/batch/public-network-access
The text was updated successfully, but these errors were encountered: