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

Updating an app service with an access restriction rule involving a VNet crashes #3760

Closed
midgleyc opened this issue Jul 1, 2019 · 3 comments

Comments

@midgleyc
Copy link

midgleyc commented Jul 1, 2019

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 (and AzureRM Provider) Version

Terraform v0.11.14

  • provider.azurerm v1.30.1

Affected Resource(s)

  • azurerm_app_service

Terraform Configuration Files

Create an app service with an access restriction rule using a VNet, then run any terraform command that updates the app service.

resource "azurerm_app_service" "test" {
  name  = "example-app-service"
  location = "West Europe"
  tags = {
      update = "${timestamp()}"
  }
}

Debug Output

https://gist.github.com/midgleyc/4bc1f27e61a696bc3c5210b28437e9a7

Expected Behavior

Terraform should apply my changes, ignoring the access restrictions.

Actual Behavior

Terraform deletes all app services from the state, then crashes.

Steps to Reproduce

Create an app service with an access restriction rule using a VNet. Import it (this works fine). Create a configuration file that will update the app service, then apply it.

Notes

The ipSecurityRestriction section for VNets looks like

    "ipSecurityRestrictions": [
      {
        "vnetSubnetResourceId": "/subscriptions/<GUID>/resourceGroups/<resourceGroup>/providers/Microsoft.Network/virtualNetworks/<network>/subnets/<subnet>",
        "action": "Allow",
        "tag": "Default",
        "priority": 1,
        "name": "vnet"
      }
    ],

This doesn't have an "ipAddress" key, so it fails the existing "ip_restriction" schema (which parses the IP Access Restriction well enough that Terraform doesn't crash). This currently shows up in the state as

                            "site_config.0.http2_enabled": "true",
                            "site_config.0.ip_restriction.#": "1",
                            "site_config.0.java_container": "",

References

This is like #3685, but while that wants a complete support of App Restrictions, I just want to be able to apply my configuration without removing and re-adding the VNet access restriction. This is also like #2488, but that one is about not breaking existing IP Address restrictions.

@mbfrahry
Copy link
Member

Hey @midgleyc, thanks for opening this issue. The crash has been found and fixed with #4184. Feel free to reopen this issue if you continue to experience problems after 1.34.0 goes out

@katbyte katbyte added this to the v1.34.0 milestone Sep 6, 2019
@ghost
Copy link

ghost commented Sep 18, 2019

This has been released in version 1.34.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 1.34.0"
}
# ... other configuration ...

@ghost
Copy link

ghost commented Sep 30, 2019

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!

@ghost ghost locked and limited conversation to collaborators Sep 30, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants