serverFarm in IDs is accepted as lowercase 'serverfarm' only #11250
Labels
Comments
|
I can concur that I have exactly the same problem: |
|
Wondering if there is any solution or workaround to this possible problem? I need to move in production but this is holding us up. |
|
as i wrote, just write "serverfarms". Referencing a plan in rhe same tf config by .id works fine or? |
|
Tried both ways:
In both cases I am getting an error (as shown below for each attempt). Environment: ########################################################################## From the crash.log file: ########################################################################## App Service Plan TF manifest: File: azurerm-ase/modules/azurerm_ase_appservice_plan/main.tf App Service TF manifest: File: azurerm-ase/modules/azurerm_ase_appservice/main.tf |
|
these are rwo different errors. your lowercase attempt causes a hard crash - something is wrong in your config. first, update terraform and azurerm |
|
Hey @jwefers , I understand these are two different errors. These two diff.errors caused by just changing letter "F" casing in 'serverfarms'. I have upgraded to the following: The same result: With 'serverFarms': Output: With 'serverfarms': Output: |
|
using lowercase "serverfams" for incoming variables works perfectly fine for me |
|
I don't know. At this point there is a discrepancy between |
|
Hi folks. From what I can see here we have 2 issues. |
|
The issue here is that Azure IDs under the hood are case insensitive - if you click around in the portal, in generated ARM templates, blabh blah, you will encounter any casing (here: camelCase), depending on the backend service you are currently hitting. Question is, what would happen if the azurerm provider becomes similarly case insensitive? |
|
Unfortunately the issue's a little more complex, Resource ID's within Azure are supposed to (per the Azure Resource Manager Specification) be Case Insensitive during Requests but Case Sensitive in Responses - but in practice, almost no Azure API implements that behaviour. It's worth calling out that since Resource ID's within Azure are URI's, which the HTTP Specification defines those as case sensitive - most custom scripts and third-party integrations also treat these as case sensitive. We've seen enough issues with things (for example an API returning a provisioning state of Within Terraform we're moving from using the Resource ID's returned in the API response to using Azure Resource ID's computed by Terraform to ensure consistency - that is, rather than using the Resource ID from the HTTP Response, pre-computing the Resource ID from what's defined within the Azure API Definitions and building up an ID for Terraform (for example we know an ASE has the segment This approach both allows us to have validation confirming that the Resource ID's match what Azure defines (and thus what we expect at import time, so we can raise an error) - and also means that we are no longer subject to changes in these ID's between different API versions (where these segments can change values entirely - as happens fairly often in the Networking API's - or casing on these). The Documentation for each Terraform Resource has a section on
Taking a look into this, it appears that we're using the Resource ID returned by Azure but validating that it matches what we expect, which'd be the problem here; instead we'll need to switch this over to using a Terraform Managed Resource ID as we've done in some other situations. It's worth noting that @jackofallops is working through the App Service resources at the moment as can be seen in #12132 - so this will be the case for the newer resources - but we are (gradually) working through the existing resources to make these consistent here. |
|
great explanation, thanks |
|
Closing this out since the Terraform side of this is now resolved, there's an upstream issue tracking the Azure SDK bug which once fixed will automatically be fixed in Terraform (with the next SDK upgrade). |
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have a terraform config that deploys service-specific resources on top of shared infra defined elsewhere. I want to deploy a functions app and for this, i pass the App service plan ID as variable into terraform:
and i pass in my var file
Terraform plan works, but apply complains:
passing it as lowercase
serverfarmsworks, but that is not the actual casing of the Azure Resource ID anymore.Community Note
Terraform (and AzureRM Provider) Version
Terraform v0.14.9
Affected Resource(s)
azurerm_function_appThe text was updated successfully, but these errors were encountered: