Fix functions app website_contenteshare unwanted changes

[uolter]

This PR wants to fix the issue described here.

#10499

Maybe some tests are missed or there might be better approaches.

[uolter]

@jackofallops I noticed you label my PR with breaking-change. Can you provide me some details?
I'd like to try to fix it in a better way.
Due to this issue #10499 the current version is also unusable.

[katbyte]

@uolter - I believe he's marked it as such because the underlying metadata setting is used by deployed apps, thus anyone not using slots could face a breaking change if this is swapped out without warning.

Ideally we would not want to change the behaviour so a fix that doesn't change the existing behaviour but fixes the specific problem would be ideal.

[uolter]

@uolter - I believe he's marked it as such because the underlying metadata setting is used by deployed apps, thus anyone not using slots could face a breaking change if this is swapped out without warning.

Ideally we would not want to change the behaviour so a fix that doesn't change the existing behaviour but fixes the specific problem would be ideal.

@katbyte I've tried a different approach not changing the current behavior, but so far no clue.
It looks to me - and correct me if I am wrong - it was a bad idea to remove the app settings WEBSITE_CONTENTSHARE
inside the read function.
https://github.com/terraform-providers/terraform-provider-azurerm/blob/057c68ea3e5e0935815433d86366ffbeb77df76e/azurerm/internal/services/web/function_app_resource.go#L687

delete(appSettings, "WEBSITE_CONTENTSHARE")

Why not let the user explicitly define that setting inside *.tf code ?

 app_settings = {
        FUNCTIONS_WORKER_RUNTIME = "node"
        WEBSITE_NODE_DEFAULT_VERSION = "~14"
        ...........
        WEBSITE_CONTENTSHARE = "staging-content"
    }
....
....
 lifecycle {
        ignore_changes = [
          app_settings["WEBSITE_CONTENTSHARE"],
        ]
    }

Forcing the creation of that setting inside the Create and Update with fixed values breaks the behavior in functions with slots when swapping. Which is very damaging and risky. It happened to me in production twice before understanding there was a bug.
How can I prevent that inside the resourceFunctionAppUpdate the WEBSITE_CONTENTSHARE does not change (in respect of what I see in the portal after swapping slots ) ?

[katbyte]

@uolter - i'm not sure there is a way to make this fix without a breaking change to the behaviour of how this resource works, it may have to way until 3.0.

[realrubberduckdev]

Hi @uolter , the ignore_changes idea in your example above, is that supposed to work now? It doesn't seem to ignore and still changes WEBSITE_CONTENTSHARE for me.

 lifecycle {
        ignore_changes = [
          app_settings["WEBSITE_CONTENTSHARE"],
        ]
    }

The only case Terraform doesn't change the value is if I ignore all.

 lifecycle {
        ignore_changes = [
          all
        ]
    }

But that will mean we cannot make changes via terraform anymore, so not really a solution.

[uolter]

Hi @uolter , the ignore_changes idea in your example above, is that supposed to work now? It doesn't seem to ignore and still changes WEBSITE_CONTENTSHARE for me.

 lifecycle {
        ignore_changes = [
          app_settings["WEBSITE_CONTENTSHARE"],
        ]
    }

The only case Terraform doesn't change the value is if I ignore all.

 lifecycle {
        ignore_changes = [
          all
        ]
    }

But that will mean we cannot make changes via terraform anymore, so not really a solution.

Hi @realrubberduckdev , it works to me, but I am working with a custom provider with changes described in this PR: https://github.com/terraform-providers/terraform-provider-azurerm/blob/057c68ea3e5e0935815433d86366ffbeb77df76e/azurerm/internal/services/web/function_app_resource.go#L687
However, it's a breaking change. It's not backwards compatible.
As I said it works to me and I do not risk anymore to break production when I run an apply after a swap I started from the portal or via azure devops pipeline.

[jackofallops]

Thanks @uolter for the PR, and apologies for the delay in getting back to it, however I'm going to close this in favour of #13349 which should handle the breaking cases by leaving existing configurations intact, but appropriately create the setting where necessary.

[github-actions]

This functionality has been released in v2.77.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!

[github-actions]

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.