Terraform detects and applies changes in azurerm_windows_web_app even though the configuration is not changed #16257

shetlinchu · 2022-04-05T09:31:17Z

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

Terraform Version

1.1.7

AzureRM Provider Version

3.0.2

Affected Resource(s)/Data Source(s)

azurerm_windows_web_app

Terraform Configuration Files

resource "azurerm_windows_web_app" "appservice" {
  name                = "${var.environment.shortlocation}-tf-appw-${var.ProjectName}-${var.DeployStage}"
  location            = azurerm_resource_group.rootrsgp01.location
  resource_group_name = azurerm_resource_group.rootrsgp01.name
  service_plan_id     = azurerm_service_plan.appserviceplan.id
  client_affinity_enabled = true

  site_config {

    ftps_state = "AllAllowed"
    always_on = true
    managed_pipeline_mode = "Integrated"
    minimum_tls_version = 1.2
    # remote_debugging = false
    use_32_bit_worker = false
    websockets_enabled = true
    
    application_stack {
      current_stack = "dotnet"
      dotnet_version = "v6.0"
    }

  }


  logs {

    detailed_error_messages = true
    failed_request_tracing = true
  }

  backup{
    name = "appservicedailybackup"
    enabled = true
    storage_account_url = "https://${azurerm_storage_account.storageccount01.name}.blob.core.windows.net/${azurerm_storage_container.appcontainer.name}${data.azurerm_storage_account_sas.stablobsas.sas}&sr=b"

    schedule {
      frequency_interval = 1
      frequency_unit = "Day"
      keep_at_least_one_backup = true
      retention_period_days = 4

    }
  }
}

Debug Output/Panic Output

2022-04-05T08:54:53.5369453Z �[1m  # azurerm_windows_web_app.appservice�[0m will be updated in-place�[0m�[0m
2022-04-05T08:54:53.5370327Z �[0m  �[33m~�[0m�[0m resource "azurerm_windows_web_app" "appservice" {
2022-04-05T08:54:53.5371809Z         �[1m�[0mid�[0m�[0m                                = "/subscriptions/f9d805c8-0231-4f5d-adc0-4e0dc34c9c2c/resourceGroups/dewc-TF-RSGP-adspaceIO-dev-01/providers/Microsoft.Web/sites/dewc-tf-appw-adspaceIO-dev-01"
2022-04-05T08:54:53.5372431Z         �[1m�[0mname�[0m�[0m                              = "dewc-tf-appw-adspaceIO-dev-01"
2022-04-05T08:54:53.5372780Z         �[1m�[0mtags�[0m�[0m                              = {}
2022-04-05T08:54:53.5373076Z         �[90m# (18 unchanged attributes hidden)�[0m�[0m
2022-04-05T08:54:53.5373512Z 
2022-04-05T08:54:53.5373640Z 
2022-04-05T08:54:53.5373750Z 
2022-04-05T08:54:53.5374075Z       �[33m~�[0m �[0mlogs {
2022-04-05T08:54:53.5374503Z             �[90m# (2 unchanged attributes hidden)�[0m�[0m
2022-04-05T08:54:53.5374749Z 
2022-04-05T08:54:53.5375150Z           �[31m-�[0m �[0mapplication_logs {
2022-04-05T08:54:53.5375687Z               �[31m-�[0m �[0m�[1m�[0mfile_system_level�[0m�[0m = "Error" �[90m->�[0m �[0m�[90mnull�[0m�[0m
2022-04-05T08:54:53.5376040Z 
2022-04-05T08:54:53.5376396Z               �[31m-�[0m �[0mazure_blob_storage {
2022-04-05T08:54:53.5377293Z                   �[31m-�[0m �[0m�[1m�[0mlevel�[0m�[0m             = "Error" �[90m->�[0m �[0m�[90mnull�[0m�[0m
2022-04-05T08:54:53.5377938Z                   �[31m-�[0m �[0m�[1m�[0mretention_in_days�[0m�[0m = 0 �[90m->�[0m �[0m�[90mnull�[0m�[0m
2022-04-05T08:54:53.5378379Z                 }
2022-04-05T08:54:53.5378568Z             }
2022-04-05T08:54:53.5378676Z 
2022-04-05T08:54:53.5378907Z           �[31m-�[0m �[0mhttp_logs {
2022-04-05T08:54:53.5379034Z 
2022-04-05T08:54:53.5379274Z               �[31m-�[0m �[0mfile_system {
2022-04-05T08:54:53.5379806Z                   �[31m-�[0m �[0m�[1m�[0mretention_in_days�[0m�[0m = 0 �[90m->�[0m �[0m�[90mnull�[0m�[0m
2022-04-05T08:54:53.5380257Z                   �[31m-�[0m �[0m�[1m�[0mretention_in_mb�[0m�[0m   = 35 �[90m->�[0m �[0m�[90mnull�[0m�[0m
2022-04-05T08:54:53.5380578Z                 }
2022-04-05T08:54:53.5380765Z             }
2022-04-05T08:54:53.5380965Z         }
2022-04-05T08:54:53.5381049Z 
2022-04-05T08:54:53.5381264Z       �[33m~�[0m �[0msite_config {
2022-04-05T08:54:53.5381579Z             �[90m# (23 unchanged attributes hidden)�[0m�[0m
2022-04-05T08:54:53.5381735Z 
2022-04-05T08:54:53.5381984Z           �[33m~�[0m �[0mapplication_stack {
2022-04-05T08:54:53.5382298Z               �[32m+�[0m �[0m�[1m�[0mcurrent_stack�[0m�[0m  = "dotnet"
2022-04-05T08:54:53.5382653Z                 �[90m# (1 unchanged attribute hidden)�[0m�[0m
2022-04-05T08:54:53.5383755Z             }
2022-04-05T08:54:53.5383959Z         }
2022-04-05T08:54:53.5384203Z         �[90m# (2 unchanged blocks hidden)�[0m�[0m
2022-04-05T08:54:53.5384467Z     }
2022-04-05T08:54:53.5384550Z

Expected Behaviour

Terraform plan should not have detected changes in the azurerm_windows_web_app because the configuration file is not changed at all.

Actual Behaviour

Terraform plan always detects and applies the same changes for the azurerm_windows_web_app in every TF Plan and TF Apply execution although the configuration for azurerm_windows_web_app has not been changed at all.

Steps to Reproduce

terraform validate
terraform plan
terraform apply

Important Factoids

No response

References

No response

vgdomi · 2022-04-08T14:40:41Z

It happens to me to. In my case with the component azurerm_linux_web_app

Terraform version: 1.1.8
AzureRM version: 3.1.0

It keeps adding the environment variables. See an extract of the terraform plan output:

          + "WEBSITE_HTTPLOGGING_RETENTION_DAYS"              = "90"
          + "WEBSITE_VNET_ROUTE_ALL"                          = "1"

No matter the resource configuration. I actually have added the properties:

resource "azurerm_linux_web_app" "this" {
  ...
  http_logs {
      file_system {
        retention_in_days = 90
        retention_in_mb   = 100
      }
    }
  ...
  site_config {
    ...
    vnet_route_all_enabled = true
    ...
  }

  app_settings {
    ...
      WEBSITE_HTTPLOGGING_RETENTION_DAYS  = 90
      WEBSITE_VNET_ROUTE_ALL = 1
    ...
  }
}

But as I said, the plan keeps adding those configuration values every time making a restart of the app service in the process which is a problem, because I cannot deploy any infrastructure change without restarting all the services without the need.

truptisatardekar · 2022-06-29T12:46:07Z

I'm facing the same issue.

And after apply, I see that the changes aren't updated in the portal

This is happening since the time we upgraded from azurerm_app_service to azurerm_windows_web_app.
I'm using terraform v1.2.2 & AzureRM provider v3.10.0.

Do you'll have solution for this?

Thanks.

xiaxyi · 2022-06-30T07:09:11Z

@truptisatardekar As the doc says, the property indicates whether all outbound traffic from the app is routed through the virtual network. A setting value of 1 indicates that all traffic is routed through the virtual network.

Can you confirm if your app meets the behavior?

Also, can you share your TF config with me?

truptisatardekar · 2022-06-30T13:05:26Z

Hello @xiaxyi
The app meets the behaviour and everything works fine. The issue here is, these settings have already gone through Terraform Plan + Terraform Apply. However, the next time I run Terraform Plan, it shows up again which from my understanding shouldn't.

KangDroid · 2022-07-05T07:37:30Z

Hi, @truptisatardekar , @xiaxyi

I faced exact same issue with "empty current stack settings issue". After some inspection, I've noticed that current_stack settings are always being reset if "site_config" is not changed during other updates.

I made Pull Requests for addressing/fixing this issue. #17490

dawsonar802 · 2022-07-15T11:21:53Z

I too am facing this issue where it seems to want to update the WEBSITE_VNET_ROUTE_ALL setting despite it being correct in TF State/App Service. I know this issues is related to azurerm_windows_web_app, however I am also seeing this with azurerm_linux_web_app...

no-op
WEBSITES_ENABLE_APP_SERVICE_STORAGE :
"true"
no-op
WEBSITE_CONTENTOVERVNET :
"1"
no-op
WEBSITE_DNS_SERVER :
"168.63.129.16"
no-op
WEBSITE_ENABLE_SYNC_UPDATE_SITE :
"1"
no-op
WEBSITE_RUN_FROM_PACKAGE :
"1"
create
WEBSITE_VNET_ROUTE_ALL :
"1"

dominik-weber · 2022-07-21T10:49:00Z

@KangDroid @truptisatardekar
Thanks for the fix! Unfortunately, we're still seeing this "empty current stack settings issue" with v3.14 :/ I just deployed a change where we modified app_settings and site_config.scm_minimum_tls_version, this change also cleared the current stack.

Here's the plan that I applied:

After applying the above, current_stack for both the app service and the slot were cleared. See second apply:

KangDroid · 2022-07-21T22:34:08Z

@KangDroid @truptisatardekar
Thanks for the fix! Unfortunately, we're still seeing this "empty current stack settings issue" with v3.14 :/ I just deployed a change where we modified app_settings and site_config.scm_minimum_tls_version, this change also cleared the current stack.

Here's the plan that I applied:

After applying the above, current_stack for both the app service and the slot were cleared. See second apply:

Hi, I applied another patch after I submit PR, but I literally forgot to add another PR since busy things are on-going on my work;

Basically what I found was : if sites configuration changes, it also resets site-config.

I will submit PR to this repo probably today(if time permits though) but if you are in hurry, can you try cherry-pick this commit to your own provider and see if fully resolved site-config issue?

dominik-weber · 2022-07-21T22:39:21Z

@KangDroid no worries, this is not an urgent issue (for us at least). As far as I can tell the app service still works with the current_stack property missing, and reapplying the same configuration adds the property back in.

kolosovpetro · 2023-02-12T17:36:46Z

Same here

blizzbox · 2023-02-15T14:41:15Z

Same here

SebastianBalle · 2023-05-17T16:04:04Z

I have the same issue with azurerm_linux_web_app resource:

resource "azurerm_linux_web_app" "this" {
  # ... other resource configuration ...

  logs {
    http_logs {
      file_system {
        retention_in_days = 30
        retention_in_mb   = 35
      }
    }
    detailed_error_messages = true
    failed_request_tracing  = true
  }
}

The configuration for retention_in_days keeps updating even if the value is not changed

      ~ logs {
            # (2 unchanged attributes hidden)
          ~ http_logs {
              ~ file_system {
                  ~ retention_in_days = 0 -> 30
                    # (1 unchanged attribute hidden)
                }
            }
        }

jincod · 2023-05-17T19:30:08Z

Hi @SebastianBalle

Make sure you don't have WEBSEITE_HTTPLOGGING_RETENTION_DAYS at configuration section

SebastianBalle · 2023-05-19T15:35:08Z

Hi @SebastianBalle

Make sure you don't have WEBSEITE_HTTPLOGGING_RETENTION_DAYS at configuration section

@jincod

The environment variable WEBSITE_HTTPLOGGING_RETENTION_DAYS is not present in my configuration section. I also explored the scm site for the App Service, but I couldn't find any indication that WEBSITE_HTTPLOGGING_RETENTION_DAYS was specified.

I would expect the retention_in_days configuration to determine the value of WEBSITE_HTTPLOGGING_RETENTION_DAYS.

jincod · 2023-05-19T19:05:16Z

@SebastianBalle please check the terraform.tfstate as well.

My guess based on

terraform-provider-azurerm/internal/services/web/app_service_resource.go

Line 735 in 155958d

delete(appSettings, "WEBSITE_HTTPLOGGING_RETENTION_DAYS")

SebastianBalle · 2023-05-22T13:37:07Z

@jincod The state file also does not contain any information around the WEBSITE_HTTPLOGGING_RETENTION_DAYS value. I see that the retention_in_days is incorrectly specified to 0 so it seems like the configuration is not correctly updated in the state file.

silambarasan · 2023-05-26T23:30:47Z

We are also facing the same issue for Linux Appservice without any changes and showing everytime on the plan and causing the application to restart,

I have updated to latest TF Version : 1.4.6 and latest RM Provider : 3.58.0 still facing the same issue.

xafierz · 2023-07-06T14:24:09Z

Just to add to @silambarasan , we are having the same problem with the windows_web_app:

JonathonAnderson · 2023-07-31T13:17:57Z

we are seeing this for the virtual application settings. The settings are already applied and the path mapping exists, but terraform plans to apply the settings every time.

mm-supernice · 2023-10-27T11:31:27Z

@stephybun I've put some detail description about the second problem in this ticket.
Basically the Issue is pretty serious because it makes the azurerm_linux_webapp resource pretty much unusable in production. I also expect this issue to exist in other scenarios too so it might worth it to check also for other occurrence.

The issue with the "WEBSITE_HTTPLOGGING_RETENTION_DAYS" variable and the "retention_in_days" setting is:

the provider does not allow to set that reserved environment variable
the provider does not add add that reserved environment variable to the state

however, setting "retention_in_days" is the way to do and of course also present in the state
On Azure itself, it does not matter if you add/set the environment variable or the explicit setting,
if you change one of them, it alters the other automatically.

In our case it causes the following:

You run terraform apply, because you made some change (independent of the logging stuff) in the linux_web_app resource.
Terraform Plan (except of your actual change) detects no change in the log retention setting because there is actually no change.
Terraform Apply pushes the JSON to the Azure API containing the actual configuration including your change.

Here we have the problem, the JSON which is PUT'ed to the Azure API contains all the environment variables but not the "WEBSITE_HTTPLOGGING_RETENTION_DAYS" because it is not allowed to set ~~and deleted as suggested bythis post~~ (edit: this post is referencing to a wrong and deprecated resource)
Furthermore, the "retention_in_days" is not part of the resource/api endpoint terraform currenty PUTs a request to, there must be another request containing that setting to <your_web_app_resource_id>/config/logs which does not happen here.
also there is no second PUT with a json to set the "retention_in_days" correctly because while terraform plan, the setting was set correctly and therefore terraform apply does not know about that change just made by himself.

change done, WEBSITE_HTTPLOGGING_RETENTION_DAYS removed, therefore automatically also "retention_in_days" removed by azure.

on the next run, terraform plan detects the missing "retention_in_days" setting and updates it, which is what you actually see as the unwanted change.

mm-supernice · 2023-10-27T13:06:20Z

Since this issue is related to another resource, i've created a ticket specifically for the log_retention bug:
#23713

jeacott1 · 2024-08-13T02:02:45Z

It also happens for me in azurerm_linux_web_app app_settings for any multiline env var I set.
nothing is changed but this always detects a change.

eg:

NGINX_CONF = file("${path.module}/nginx.conf")
or
NGINX_CONF =<<EOF
xyz
EOF

shetlinchu added the bug label Apr 5, 2022

github-actions bot removed the bug label Apr 5, 2022

stephybun added bug service/app-service labels Apr 5, 2022

KangDroid mentioned this issue Jul 4, 2022

windows_web_app_(slot)_resource: Fix currentStack is not fetched from state when updating infrastructure using terraform. #17490

Merged

KangDroid mentioned this issue Sep 29, 2022

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

Merged

Jazun713 mentioned this issue Feb 1, 2023

Application settings are reset for azurerm_windows_web_app #20159

Open

1 task

catriona-m added the v/3.x label Jul 19, 2023

mm-supernice mentioned this issue Oct 27, 2023

retention_in_days setting falsely removed on any other change in linux_web_app #23713

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Terraform detects and applies changes in azurerm_windows_web_app even though the configuration is not changed #16257

Terraform detects and applies changes in azurerm_windows_web_app even though the configuration is not changed #16257

shetlinchu commented Apr 5, 2022

vgdomi commented Apr 8, 2022 •

edited

Loading

truptisatardekar commented Jun 29, 2022 •

edited

Loading

xiaxyi commented Jun 30, 2022 •

edited

Loading

truptisatardekar commented Jun 30, 2022

KangDroid commented Jul 5, 2022

dawsonar802 commented Jul 15, 2022

dominik-weber commented Jul 21, 2022

KangDroid commented Jul 21, 2022

dominik-weber commented Jul 21, 2022

kolosovpetro commented Feb 12, 2023

blizzbox commented Feb 15, 2023

SebastianBalle commented May 17, 2023

jincod commented May 17, 2023

SebastianBalle commented May 19, 2023

jincod commented May 19, 2023

SebastianBalle commented May 22, 2023 •

edited

Loading

silambarasan commented May 26, 2023 •

edited

Loading

xafierz commented Jul 6, 2023

JonathonAnderson commented Jul 31, 2023

mm-supernice commented Oct 27, 2023 •

edited

Loading

mm-supernice commented Oct 27, 2023

jeacott1 commented Aug 13, 2024

Terraform detects and applies changes in azurerm_windows_web_app even though the configuration is not changed #16257

Terraform detects and applies changes in azurerm_windows_web_app even though the configuration is not changed #16257

Comments

shetlinchu commented Apr 5, 2022

Is there an existing issue for this?

Community Note

Terraform Version

AzureRM Provider Version

Affected Resource(s)/Data Source(s)

Terraform Configuration Files

Debug Output/Panic Output

Expected Behaviour

Actual Behaviour

Steps to Reproduce

Important Factoids

References

vgdomi commented Apr 8, 2022 • edited Loading

truptisatardekar commented Jun 29, 2022 • edited Loading

xiaxyi commented Jun 30, 2022 • edited Loading

truptisatardekar commented Jun 30, 2022

KangDroid commented Jul 5, 2022

dawsonar802 commented Jul 15, 2022

dominik-weber commented Jul 21, 2022

KangDroid commented Jul 21, 2022

dominik-weber commented Jul 21, 2022

kolosovpetro commented Feb 12, 2023

blizzbox commented Feb 15, 2023

SebastianBalle commented May 17, 2023

jincod commented May 17, 2023

SebastianBalle commented May 19, 2023

jincod commented May 19, 2023

SebastianBalle commented May 22, 2023 • edited Loading

silambarasan commented May 26, 2023 • edited Loading

xafierz commented Jul 6, 2023

JonathonAnderson commented Jul 31, 2023

mm-supernice commented Oct 27, 2023 • edited Loading

mm-supernice commented Oct 27, 2023

jeacott1 commented Aug 13, 2024

vgdomi commented Apr 8, 2022 •

edited

Loading

truptisatardekar commented Jun 29, 2022 •

edited

Loading

xiaxyi commented Jun 30, 2022 •

edited

Loading

SebastianBalle commented May 22, 2023 •

edited

Loading

silambarasan commented May 26, 2023 •

edited

Loading

mm-supernice commented Oct 27, 2023 •

edited

Loading