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

azurerm_function_app - address app_settings on create rather than just on update #14638

Merged
merged 1 commit into from
Dec 16, 2021

Conversation

jackofallops
Copy link
Member

Fixes #10990
Supersedes #14521

@jackofallops jackofallops added the service/functions Function Apps label Dec 16, 2021
@jackofallops jackofallops added this to the v2.90.0 milestone Dec 16, 2021
@jackofallops jackofallops requested a review from a team December 16, 2021 12:31
@jackofallops jackofallops self-assigned this Dec 16, 2021
@jackofallops jackofallops mentioned this pull request Dec 16, 2021
Copy link
Contributor

@cmendible cmendible left a comment

Choose a reason for hiding this comment

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

@jackofallops
Copy link
Member Author

Hi @cmendible - I don't believe the additional test is necessary. The issue for that particular case was that the settings were not applied during the initial creation of the resource, so that when Terraform got to the Update step that the resource was previously relying on to apply the settings, it was already behind the private link, so inaccessible. The change here applies the user configured app_settings in the initial creation payload, avoiding the scenario you've experienced.

FWIW - This resource is in the process of being superseded by azurerm_linux_function_app and azurerm_windows_function_app, currently in beta. These will be promoted out of beta as part of the 3.0 major release, at which point the older resources will be marked as deprecated (albeit still available).

@cmendible
Copy link
Contributor

Hi @cmendible - I don't believe the additional test is necessary. The issue for that particular case was that the settings were not applied during the initial creation of the resource, so that when Terraform got to the Update step that the resource was previously relying on to apply the settings, it was already behind the private link, so inaccessible. The change here applies the user configured app_settings in the initial creation payload, avoiding the scenario you've experienced.

FWIW - This resource is in the process of being superseded by azurerm_linux_function_app and azurerm_windows_function_app, currently in beta. These will be promoted out of beta as part of the 3.0 major release, at which point the older resources will be marked as deprecated (albeit still available).

Perfect! looking forward for both versions then! 😉

Copy link
Collaborator

@katbyte katbyte left a comment

Choose a reason for hiding this comment

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

Thanks @jackofallops - LGTM 🏗️

@katbyte katbyte merged commit aba13d2 into main Dec 16, 2021
@katbyte katbyte deleted the b/function-app-settings-GH10990 branch December 16, 2021 18:55
katbyte added a commit that referenced this pull request Dec 16, 2021
@github-actions
Copy link

This functionality has been released in v2.90.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
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 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
3 participants