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

Feature Request: split azurerm_application_gateway into multiple resources #727

Closed
jansepke opened this issue Jan 19, 2018 · 4 comments
Closed

Comments

@jansepke
Copy link
Contributor

Hi,

would it be possible to split the azurerm_application_gateway resource into multiple other? so that one can create backends, listeners and rules in another file. Also then one could use count in the sub-resources, which is not possible right now. Maybe you could start with backend_address_pool because this has relations to other terraform azure resources.

Terraform Version

Terraform v0.11.1

  • provider.azurerm v1.0.0

Affected Resource(s)

  • azurerm_application_gateway
@tombuildsstuff
Copy link
Contributor

hey @jansepke

Thanks for opening this issue

would it be possible to split the azurerm_application_gateway resource into multiple other? so that one can create backends, listeners and rules in another file. Also then one could use count in the sub-resources, which is not possible right now. Maybe you could start with backend_address_pool because this has relations to other terraform azure resources.

So back when we were first supporting this resource we were hoping to take this approach - however after some investigation it appears the API is set up different from the Load Balancer API (which uses the approach you've specified) such that it's not possible.

In the Load Balancer resources we essentially create an empty Load Balancer with all sub-fields (such as the Probes) as empty lists - and then when making any changes we pull the latest information about the Load Balancer and update the relevant field, for instance we add a new Probe.

Unfortunately the Application Gateway API requires almost all of the Application Gateway sub-objects to be specified, such that whilst we could do this for a few of the sub-objects (from memory fields like url_path_map, application_certificate and the waf_configuration blocks) - most of the benefit would come from splitting out the other fields (as you've outlined above).

In order to proceed with this we'd need the API to be updated to handle this - I'll raise this through our internal channels, but it might be worth opening an issue on the Rest API Specs Repository so that the Application Gateway team could better understand the use-case.


Separately to this there's a feature request in Terraform Core which may help with this that you may be interested in/wish to subscribe to: https://github.com/hashicorp/terraform/issues/2275


Given there's not a lot we can do with this issue in the foreseeable future, I'm going to close this issue for the moment. However should support become available for this in the API (and/or the SDK) - we'll certainly look to support this.

Thanks!

@boillodmanuel
Copy link
Contributor

Asked on azure feedback site : https://feedback.azure.com/forums/217313-networking/suggestions/39634519-allow-creation-of-an-empty-application-gateway
If people following this issue could vote on it, it will be great 👍

@boillodmanuel
Copy link
Contributor

Asked also for related feature request: https://feedback.azure.com/forums/217313-networking/suggestions/39634588-add-rest-apis-and-sdk-to-manage-application-gatewa
If people following this issue could vote on it, it will be great 👍

@ghost
Copy link

ghost commented Feb 5, 2020

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 👉 [email protected]. Thanks!

@ghost ghost locked and limited conversation to collaborators Feb 5, 2020
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