-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Resource ID validation for serverFarms element when referencing azurerm_service_plan resource #24727
Comments
We are having this same problem for our organization. Please escalate this issue. |
Hi @bargokr , Thanks for raising this issue, we migrated the SDK for azure service plan and the legacy app service plan so the resource ID use the camel case now, 3.89 is not supposed to receive the validation error after the PR was merged, so can you confirm about the "serverFarms" validation error you received? Besides of the ID issue, would you mind sharing more details about the api error you got when you tried to create the app slot? can you share the config with me and can you try creating the slot in azure portal/ cli/ PowerShell, just to make sure the service plan & the app is in a healthy state and ready to host the slot. If this is an urgent issue and your production is being affected, I recommend opening a support ticket with MS support and provide your app's resource ID so the product group can check the status from the backend server. let me know if you have any question. |
@xiaxyi That PR only fixes things for the legacy resource. It doesn't appear the same was done for azurerm_service_plan. We can build a Service Plan and Function App if we reference the Service Plan Resource ID in camelCase or pull from the Service Plan ID from the Terraform output which is also camelCase.
Creating the azurerm_windows_function_app_slot resource, however, fails with the error below. We are able to create the slot manually in the portal with no issue. This is only happening after the 3.88 provider push. This is not a Microsoft issue. We can only workaround this currently by pinning the provider to 3.87 and lowercasing any references to the Service Plan.
Tagging @tombuildsstuff and @jackofallops as they have worked some of the other issues relating to the SDK update where the camelCase has caused various other validation issues in other resources. |
@bdorplatt unfortunately this is ultimately an API issue (since the API is returning a 500 for a valid value) - and as such that would need to be resolved by the Service Team (and as such I'm going to tag this The Azure API is supposed to be case-insensitive in Requests and case-sensitive in Responses - however since the API is returning a 500 when providing the same value in a different casing - this issue would need to be resolved by the Service Team. @xiaxyi would you mind opening an ICM so that the Service Team can look into this? |
@tombuildsstuff Thank you for looking at this. Can any logic be added for the azurerm_windows_function_app_slot resource to get past this like has been done for other resources where this problem has arisen this week? Or is this a totally different issue? |
I can open the icm, however, I think that may not be the good idea since the service team need the resource ID and other information that may contains the sensitive data, I don't think it's safe to share that information in an open platform like github. @bdorplatt Would you mind opening a support ticket and share your function app id with MS support engineer via internal channel, they will help to get the icm created. |
I think this issue is impacting all new function app slot builds on the latest version. I don't think this issue is on MS end, so MS ticket is not going to get anywhere..... Provider version: 3.89.0 |
I'm not sure why this is being pushed back on us to open a Microsoft case. This isn't specific to our deployment. @xiaxyi try building a Service Plan with a Function App and Function App slot with provider version 3.89 and you should be able to easily reproduce this error for troubleshooting. I don't think this problem is getting the proper attention and is going to cause problems for a lot of organizations once they move to the latest provider. This was a major breaking change introduce in provider version 3.88. I don't feel this should be the customer's responsibility to troubleshoot with Microsoft. |
@bdorplatt @LoganHealy I created the linux function app and the slot using the latest 3.90 provider but I didn't get the 500 error.. I used the simplest config as below:
I also tried to create the service plan using terraform azurerm 3.80 provider to create the slot then upgrade the provider to 3.90, both new slot and existed slot that created using 3.80 can be updated without any issue. By any chance that you can share your TF config with me so I can try again? |
Can you please re-attempt this with the windows function app / slot? That is what is failing for us. Config below (trimmed out some dynamic blocks that are not required). Not sure how helpful this is since its all variablized. |
@bargokr Thanks for the information, windows function app also works as expected:
Have you tried update the windows function app slot using another client tool such as azure cli/ azure portal, just to make sure the slot is in a healthy state, so the issue can be narrowed down as well. |
@xiaxyi @tombuildsstuff @jackofallops Working config with virtual_network_subnet_id commented out:
|
Provider version 3.91 seems to have resolved this but we aren't able to find anything related specified in the release notes. Can someone identify which commit this fix was applied as part of? https://github.com/hashicorp/terraform-provider-azurerm/releases/tag/v3.91.0 |
👋 @bdorplatt |
Still seeing this issue on AzureRM 3.97.1.
I looked up https://github.com/search?q=repo%3Ahashicorp%2Fgo-azure-helpers%20staticServerFarms&type=code but can't tell how it's supposed to be case insensitive. |
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.6.4
AzureRM Provider Version
3.89.0
Affected Resource(s)/Data Source(s)
azurerm_service_plan azurerm_windows_function_app azurerm_windows_function_app_slot
Terraform Configuration Files
There was a fix applied for the the deprecated app service plan/function app/function app slot resources in PR #24626
We are seeing the same issue with the non-deprecated equivalents of these resources. We are seeing "serverFarms" being parsed case sensitive as of provider version 3.88 and had to pin to 3.87 to get things going again as the problem persists in 3.89.
The resources we are using are:
Debug Output/Panic Output
Error we are seeing if we reference a resource ID as "serverfarms" when building a resource based on azurerm_windows_function_app
Error we are seeing if we change the reference to "serverFarms" which allows the plan and apply to complete for the ASP and Function App but then fails on the apply for Windows Function App Slot creation:
│ Error: creating Windows Function App Slot: (Slot Name "dev" / Site Name "test-azf" / Resource Group "test-rg"): web.AppsClient#CreateOrUpdateSlot: Failure sending request: StatusCode=500 -- Original Error: Code="Failed" Message="The async operation failed." AdditionalInfo=[{"Message":"An error has occurred."}]
Expected Behaviour
Case for serverfarms element should be ignored
Actual Behaviour
Deployment fails
Steps to Reproduce
No response
Important Factoids
No response
References
No response
The text was updated successfully, but these errors were encountered: