shetlinchu commented 2 years ago

Is there an existing issue for this?

[X] I have searched the existing issues

Community Note

Please vote on this issue by adding a :thumbsup: 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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. https://github.com/hashicorp/terraform-provider-azurerm/pull/17490

dawsonar802 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 1 year ago

Same here

blizzbox commented 1 year ago

Same here

SebastianBalle commented 1 year ago

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 commented 1 year ago

Hi @SebastianBalle

Make sure you don't have WEBSEITE_HTTPLOGGING_RETENTION_DAYS at configuration section

SebastianBalle commented 1 year ago

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 commented 1 year ago

@SebastianBalle please check the terraform.tfstate as well.

My guess based on https://github.com/hashicorp/terraform-provider-azurerm/blob/155958d2cb0845d598dc78367ca6393fd9ff3cac/internal/services/web/app_service_resource.go#L735

SebastianBalle commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

JonathonAnderson commented 1 year ago

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 commented 1 year ago

@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 /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 commented 1 year ago

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

23713

jeacott1 commented 3 months ago

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

hashicorp / terraform-provider-azurerm

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

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

23713