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

use_32_bit_worker_process doesn't work #3146

Closed
Leon99 opened this issue Mar 29, 2019 · 4 comments · Fixed by #3219
Closed

use_32_bit_worker_process doesn't work #3146

Leon99 opened this issue Mar 29, 2019 · 4 comments · Fixed by #3219

Comments

@Leon99
Copy link

Leon99 commented Mar 29, 2019

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

Terraform (and AzureRM Provider) Version

Terraform v0.11.13
+ provider.azurerm v1.23.0

Affected Resource(s)

  • azurerm_app_service,azurerm_app_service_slot

Expected Behavior

  • switching the app service's platform from 32 to 64 Bit in the Azure portal is detected by terraform given the presence of use_32_bit_worker_process = true (which, BTW, worked at some point)
  • removing use_32_bit_worker_process = true switches the app service's platform to 64 Bit given it was set to 32 bit.

Actual Behavior

Nothing happens in the scenarios mentioned above

Steps to Reproduce

  1. terraform apply
@Lucretius
Copy link
Contributor

I am not familiar with this azure resource but from looking at the code:

use_32_bit_worker_process is considered a computed property which does not change based on user input after creation.† That would explain why changing this property does nothing.

Are you able to create app_services from scratch with use_32_bit_worker_process set to true or false and just changing it/removing the property does not appear to work?

† Found this comment in the terraform schema code from which I am making this assertion:

	// If Computed is true, then the result of this value is computed
	// (unless specified by config) on creation.

@bojingo
Copy link

bojingo commented Apr 5, 2019

@Lucretius - use_32_bit_worker_process is most certainly an attribute we should be able to change based on user input. In the Azure Portal there is a toggle button for App Services where this can be toggled.


Not sure this is exactly related to this issue, but I had a challenge with this attribute where I had an App Service Plan in Standard tier with an application within it that had use_32_bit_worker_process: false. I wanted to change this App Service Plan to Free tier to save cost on our development environment. The caveat is that use_32_bit_worker_process must be true for Free tier because the Free tier doesn't support 64-bit processes. So, I flipped the property to true in Terraform config definition of the App Service.

The Terraform plan was generated fine, showing both resources changing, but when I applied I got an error because the App Service Plan was attempted to be changed first, which put it in an incompatible mode so the operation failed. It should have sequenced it the other way around: update the App Service to use_32_bit_worker_process: true before changing the App Service Plan to the Free tier. To get past this I manually flipped the bit-ness of the App Service in the Azure Portal and then re-planned and applied the Terraform config successfully.

@Lucretius
Copy link
Contributor

@bojingo thank you for the additional information here, it's really helpful. It sounds like we want to make the use_32_bit_worker_process non-computed. I believe any attempted changes to it are ignored because it's a computed property - which means that when you tried to change both that and the app service plan, it never tried to change use_32_bit_worker_process --- the API calls should be making one big change to the resource.

@ghost
Copy link

ghost commented May 16, 2019

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators May 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants