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

Resource ID validation for serverFarms element when referencing azurerm_service_plan resource #24727

Closed
1 task done
bdorplatt opened this issue Jan 31, 2024 · 16 comments
Closed
1 task done
Labels
service/app-service upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. v/3.x

Comments

@bdorplatt
Copy link

bdorplatt commented Jan 31, 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 "+1" or "me too" comments, 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.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:

azurerm_service_plan
azurerm_windows_function_app
azurerm_windows_function_app_slot

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

│ The parsed Resource ID was missing a value for the segment at position 6
│ (which should be the literal value "serverFarms").

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

@bargokr
Copy link

bargokr commented Feb 1, 2024

We are having this same problem for our organization. Please escalate this issue.

@xiaxyi
Copy link
Contributor

xiaxyi commented Feb 2, 2024

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.

@bdorplatt
Copy link
Author

bdorplatt commented Feb 2, 2024

@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.

/subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/test-rg/providers/Microsoft.Web/serverFarms/test-asp

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.

│ 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."}]

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.

@tombuildsstuff
Copy link
Contributor

tombuildsstuff commented Feb 2, 2024

@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 upstream/microsoft).

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 tombuildsstuff added the upstream/microsoft Indicates that there's an upstream issue blocking this issue/PR label Feb 2, 2024
@bdorplatt
Copy link
Author

@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?

@rcskosir rcskosir added upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. and removed upstream/microsoft Indicates that there's an upstream issue blocking this issue/PR labels Feb 2, 2024
@xiaxyi
Copy link
Contributor

xiaxyi commented Feb 4, 2024

@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 upstream/microsoft).

The Azure API is supposed to be case-insensitive in Requests and case-insensitive 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?

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.

@LoganHealy
Copy link

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

@bdorplatt
Copy link
Author

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.

@xiaxyi
Copy link
Contributor

xiaxyi commented Feb 6, 2024

@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:

azurerm_service_plan.test: Creating...
azurerm_service_plan.test: Still creating... [10s elapsed]
azurerm_service_plan.test: Still creating... [20s elapsed]
azurerm_service_plan.test: Creation complete after 20s [id=/subscriptions/85xxx/resourceGroups/xiaxin-asp-slot/providers/Microsoft.Web/serverFarms/xiaxinasp-newprovider]
azurerm_linux_function_app_slot.test: Creating...
azurerm_linux_function_app_slot.test: Still creating... [10s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [20s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [30s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [40s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [50s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m0s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m10s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m20s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m30s elapsed]
azurerm_linux_function_app_slot.test: Creation complete after 1m33s [id=/subscriptions/85xxx/resourceGroups/xiaxin-asp-slot/providers/Microsoft.Web/sites/xiaxintest-LFA-asp-slot/slots/xiaxintest-LFAS-asp]

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?

@bargokr
Copy link

bargokr commented Feb 6, 2024

@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:

azurerm_service_plan.test: Creating...
azurerm_service_plan.test: Still creating... [10s elapsed]
azurerm_service_plan.test: Still creating... [20s elapsed]
azurerm_service_plan.test: Creation complete after 20s [id=/subscriptions/85xxx/resourceGroups/xiaxin-asp-slot/providers/Microsoft.Web/serverFarms/xiaxinasp-newprovider]
azurerm_linux_function_app_slot.test: Creating...
azurerm_linux_function_app_slot.test: Still creating... [10s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [20s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [30s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [40s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [50s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m0s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m10s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m20s elapsed]
azurerm_linux_function_app_slot.test: Still creating... [1m30s elapsed]
azurerm_linux_function_app_slot.test: Creation complete after 1m33s [id=/subscriptions/85xxx/resourceGroups/xiaxin-asp-slot/providers/Microsoft.Web/sites/xiaxintest-LFA-asp-slot/slots/xiaxintest-LFAS-asp]

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.

Source Code

@xiaxyi
Copy link
Contributor

xiaxyi commented Feb 7, 2024

@bargokr Thanks for the information, windows function app also works as expected:

azurerm_service_plan.test-windows: Still creating... [10s elapsed]
azurerm_service_plan.test-windows: Still creating... [20s elapsed]
azurerm_service_plan.test-windows: Creation complete after 27s [id=/subscriptions/85xxx/resourceGroups/xiaxin-asp-slot-380/providers/Microsoft.Web/serverFarms/xiaxinasp-380-windows]
azurerm_windows_function_app.test: Creating...
azurerm_windows_function_app.test: Still creating... [10s elapsed]
azurerm_windows_function_app.test: Still creating... [20s elapsed]
azurerm_windows_function_app.test: Still creating... [30s elapsed]
azurerm_windows_function_app.test: Still creating... [40s elapsed]
azurerm_windows_function_app.test: Still creating... [50s elapsed]
azurerm_windows_function_app.test: Still creating... [1m0s elapsed]
azurerm_windows_function_app.test: Creation complete after 1m19s [id=/subscriptions/85xxx/resourceGroups/xiaxin-asp-slot-380/providers/Microsoft.Web/sites/xiaxintest-WFA-asp-slot380]
azurerm_windows_function_app_slot.test: Creating...
azurerm_windows_function_app_slot.test: Still creating... [10s elapsed]
azurerm_windows_function_app_slot.test: Still creating... [20s elapsed]
azurerm_windows_function_app_slot.test: Still creating... [30s elapsed]
azurerm_windows_function_app_slot.test: Still creating... [40s elapsed]
azurerm_windows_function_app_slot.test: Still creating... [50s elapsed]
azurerm_windows_function_app_slot.test: Still creating... [1m0s elapsed]
azurerm_windows_function_app_slot.test: Still creating... [1m10s elapsed]
azurerm_windows_function_app_slot.test: Still creating... [1m20s elapsed]
azurerm_windows_function_app_slot.test: Creation complete after 1m23s [id=/subscriptions/85xxx/resourceGroups/xiaxin-asp-slot-380/providers/Microsoft.Web/sites/xiaxintest-WFA-asp-slot380/slots/xiaxintest-WFAS-asp380]

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.

@bdorplatt
Copy link
Author

@xiaxyi @tombuildsstuff @jackofallops
We tested with a base config without any additional options configured using the 3.90 provider and were able to get the slot to build. Through trial and error, we were able to narrow the problem down to vnet integration being enabled on the Windows Function app slot. If we do not supply a value for virtual_network_subnet_id, the slot builds correctly.
With this new information, we located another issue #24618 where it has been reported for azurerm_windows_web_app_slot as well as comments mention it affecting azurerm_windows_function_app_slot when using any provider version 3.88 to 3.90. With this new information, can you re-test and troubleshoot the cause of the issue?

Working config with virtual_network_subnet_id commented out:

resource "azurerm_resource_group" "fawintest" {
  name     = "fawintest-rg"
  location = "North Central US"
}

resource "azurerm_storage_account" "fawintest" {
  name                     = "functionappsa"
  resource_group_name      = azurerm_resource_group.fawintest.name
  location                 = azurerm_resource_group.fawintest.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_service_plan" "fawintest" {
  name                = "fawintest-asp"
  resource_group_name = azurerm_resource_group.fawintest.name
  location            = azurerm_resource_group.fawintest.location
  os_type             = "Windows"
  sku_name            = "Y1"
}

resource "azurerm_windows_function_app" "fawintest" {
  name                 = "fawintest-windows-fa"
  https_only           = true
  resource_group_name  = azurerm_resource_group.fawintest.name
  location             = azurerm_resource_group.fawintest.location
  storage_account_name = azurerm_storage_account.fawintest.name
  storage_account_access_key = azurerm_storage_account.fawintest.primary_access_key
  service_plan_id      = azurerm_service_plan.fawintest.id

  site_config {}
}

resource "azurerm_windows_function_app_slot" "fawintest" {
  name                 = "fawintest-windows-fa-slot"
  https_only           = true
  function_app_id      = azurerm_windows_function_app.fawintest.id
  ###virtual_network_subnet_id   = var.virtual_network_subnet_id
  storage_account_name = azurerm_storage_account.fawintest.name
  storage_account_access_key = azurerm_storage_account.fawintest.primary_access_key

  site_config {}
}

@bdorplatt
Copy link
Author

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

@rcskosir
Copy link
Contributor

👋 @bdorplatt
It looks like this has been resolved with this part of the release: commonids.ParseAppServiceEnvironmentIDInsensitively(). As such, I am going to mark this issue as closed. If that is not the case, please provide additional information including the version in which you are still experiencing this issue, thanks!

@DamonStamper
Copy link

Still seeing this issue on AzureRM 3.97.1.

Error: parsing "/subscriptions/*ID*/resourceGroups/*RG*/providers/Microsoft.Web/serverfarms/*name*": parsing segment "staticServerFarms": parsing the AppServicePlan ID: the segment at position 6 didn't match

Expected a AppServicePlan ID that matched:

> /subscriptions/12345678-1234-9876-4563-123456789012/resourceGroups/example-resource-group/providers/Microsoft.Web/serverFarms/serverFarmValue

However this value was provided:

> /subscriptions/*ID*/resourceGroups/*RG*/providers/Microsoft.Web/serverfarms/*name*

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.

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 Apr 27, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
service/app-service upstream/microsoft/blocking-api-issue This label is applicable when there is a bug on the Azure API that is blocking. v/3.x
Projects
None yet
Development

No branches or pull requests

7 participants