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

Fix currentStack is being reset when other site_config values are changed. #18568

Merged
merged 1 commit into from
Nov 28, 2022

Conversation

KangDroid
Copy link
Contributor

@KangDroid KangDroid commented Sep 29, 2022

Background(Problem)

Few months ago, I've submitted PR that fixes current_stack is always being reset every time we update azure app service(windows) infrastructure.

After time passes, I've identified that whenever site_config's value changes - is resets site_config again.
Again, it turns out I had to double-apply all the time whenever I apply updates to Azure infrastructure.

Investigation & Possible Cause

With little golang knowledge and Terraform Azure RM Provider's architecture style, I've found that currentStack variable in internal/services/appservice/helpers/web_app_schema.go : func ExpandSiteConfigWindows is always being reset when site_config expansion starts. - But if metadata.ResourceData.HasChange("site_config.0.application_stack") is false, meaning user did not really intended to modify application_stack - it never expands application_stack and set to empty value and sent empty value to app service.

However, if user intended to change application_stack, it will update application_stack correctly.

Reproduce?

  1. Create any windows app service(slot does not matter.)
  2. Set site_config value(anything, i.e health_check)
  3. Apply - provision infrastructure.
  4. After provisioning, modify site_config's value(i.e remove health_check)
  5. Apply - provision infrastructure.
  6. After provisioning(updating) call terraform plan
  7. Notice there is "current_stack" changes.

Solutions

Related Issues

Others

Please let me know if I am doing something wrong. Feedbacks, other suggestions are always welcome!
Thanks 👍

@peterprumbach-telekom
Copy link

Mentioned the same problem when applying azurerm_windows_web_app
#18636

@sehgalnamit
Copy link
Contributor

Hi, when can we get this PR merged?

@sehgalnamit
Copy link
Contributor

@katbyte Can you please check this PR?

@sehgalnamit
Copy link
Contributor

sehgalnamit commented Nov 17, 2022

@jackofallops Can please help to review and merge?
Sorry to chase you but it is blocking our automation with current provider.

@gommo
Copy link

gommo commented Nov 20, 2022

Yes, please try get this released. It's affecting us too, where we have to double apply each time

Copy link
Member

@jackofallops jackofallops left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @KangDroid
This LGTM 👍

@jackofallops jackofallops added this to the v3.34.0 milestone Nov 28, 2022
@jackofallops jackofallops merged commit 74691c7 into hashicorp:main Nov 28, 2022
jackofallops added a commit that referenced this pull request Nov 28, 2022
harshavmb pushed a commit to AmadeusITGroup/terraform-provider-azurerm that referenced this pull request Nov 28, 2022
…nged. (hashicorp#18568)

Co-authored-by: KangDroid <kangdroid@outlook.com>
harshavmb pushed a commit to AmadeusITGroup/terraform-provider-azurerm that referenced this pull request Nov 28, 2022
@github-actions
Copy link

github-actions bot commented Dec 2, 2022

This functionality has been released in v3.34.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!

@gommo
Copy link

gommo commented Dec 5, 2022

I just ran 3.34 on our appservice and after applying once, and then rerunning a plan I still get a change showing it wants to turn dotnet 4.0 to dotnetcore core3.1 -
It's like it never sets dotnetcode core3.1 properly in terraform state. The actual appservice is set to 3.1 but terraform never seems to know that? Even after this fix??

https://app.screencast.com/SDKV950PZXVzQ?conversation=N0roBpGiXhD85fw3hJpBxG

Can anyone see what I'm missing?

@sehgalnamit
Copy link
Contributor

I see the issue is with:-

2022-12-15 12:13:28 + application_stack {
2022-12-15 12:13:28 + php_version = "7.4"
2022-12-15 12:13:28 }
2022-12-15 12:13:28 }

application_stack is not getting applied for azurerm-windows-web-app but it is applied for azurerm-linux-web-app
@jackofallops @KangDroid possible to check this issue?

@sehgalnamit
Copy link
Contributor

You can ignore it seems to work for me now.
application_stack = {
current_stack = "dotnet" << I was missing this.
dotnet_version = "v4.0"
}

2022-12-15 13:15:52 ~ site_config {
2022-12-15 13:15:52 # (23 unchanged attributes hidden)
2022-12-15 13:15:52
2022-12-15 13:15:52
2022-12-15 13:15:52 - virtual_application {
2022-12-15 13:15:52 - physical_path = "site\wwwroot" -> null
2022-12-15 13:15:52 - preload = false -> null
2022-12-15 13:15:52 - virtual_path = "/" -> null
2022-12-15 13:15:52 }
2022-12-15 13:15:52 # (1 unchanged block hidden)
2022-12-15 13:15:52 }
2022-12-15 13:15:52 # (2 unchanged blocks hidden)
2022-12-15 13:15:52 }
2022-12-15 13:15:52

Used
terraform {
required_version = ">= 0.14"
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "= 3.34.0"
}
}
}

-- Tested
2022-12-15 13:15:51 ~ application_stack {
2022-12-15 13:15:51 ~ dotnet_version = "v7.0" -> "v4.0"
2022-12-15 13:15:51 # (1 unchanged attribute hidden)
2022-12-15 13:15:51 }

favoretti pushed a commit to favoretti/terraform-provider-azurerm that referenced this pull request Jan 12, 2023
…nged. (hashicorp#18568)

Co-authored-by: KangDroid <kangdroid@outlook.com>
favoretti pushed a commit to favoretti/terraform-provider-azurerm that referenced this pull request Jan 12, 2023
@github-actions
Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, 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 Jan 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants