terraform-provider-azurerm: Order of Application Gateway Configuration Blocks Should be Irrelvant
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.12.24
- provider.azurerm v2.8.0
Affected Resource(s)
azurerm_application_gateway
Issue Description
The order of certain configuration blocks (like http_listener) seems to relevant to the azurerm provider. If you swap the order of two blocks in your configuration file, the azurerm provider plans to update both existing elements (by replacing each attribute). For other blocks (like probe) this is working fine.
Terraform Configuration Files
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key: https://keybase.io/hashicorp
Expected Behavior
The order of the configuration blocks should be irrelevant. Terraform should not plan any updates, if only the order of two blocks changes.
Actual Behavior
Terraform sticks to the order in the configuration file and plans unnecessary updates.
Steps to Reproduce
Define an azurerm_application_gateway resource with at least 2 configuration blocks of the following types:
http_listenerbackend_http_settingsredirect_configurationssl_certificaterequest_routing_ruleprobe
Deploy the application gateway.
Swap the order of each configuration block pair.
Plan a new deployment and investigate the plan:
While there is no change in the list request_routing_rule and probe, all other blocks are marked for modification. Terraform plans to swap the content of each element.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 61
- Comments: 25 (4 by maintainers)
This is one of the biggest annoyances when making changes to app gateways. Most of the changes I make to a gateway is the addition of a listener/rule combination, which are handled dynamically in my config based on variables because I have to deploy to separate environments. Adding or removing a single item causes terraform to plan the deletion and addition of hundreds of lines of configuration; the plans produced are basically useless for reviewing what changes are actually about to be applied.
I see in #7021 that the fix was submitted in a PR, but it was been deemed a breaking change and pushed off to v3.0 of the provider. Iâm unclear as to why the fix would be a breaking change for existing configs in most use cases. Wouldnât the actual config syntax for the change from schema.TypeList to schema.TypeSet be basically identical except that TypeSet doesnât allow for duplicates? I suppose itâs possible that someone has the same config block with exactly the same values defined twice on an app gateway, but that seems like an edge case and most likely accidental as such a configuration wouldnât provide any functional value (would such a configuration even be accepted by the api?). If this change is breaking, isnât that what the ability to specify provider version requirements is for?
Breaking changes have been introduced between major versions previously. Itâs really disappointing be stuck waiting for a major revision that has been under development for over a year and has no ETA just to get a simple fix that has already been developed and solves a major headache.
TL;DR, I feel like this change should be prioritized for release before v3.0 of the provider.
sorry, but since most comments in #16136 seem to be marked as âoff topicâ, could you please reopen this original issue. If you read the original post in this issue carefully, it doesnât really matter what you change internally, if the end result is that the issue still persists in 3.x.x. itâs nice that some internal restructuring took place, but right now the state is âwe did all we could, but terraform reports a change, because the azure api returns unordered listsâ (as is my understanding, please correct me). This should not be a reason to close an issue as solved.
As an architect, this is pointing to a (really consistant and de facto industry standard) upstream APIs as the scape goat. If you go further down the ticket rabbithole, you even reach the point where Azure itself is the problem, not sorting the returned values for the terraform provider pass through to terraform without additional transformations. Which is frustrating, because my customers think Iâm insane pointing out that an MS framework is buggy because of another MS framework, and all the tickets get put off because of ânot our problemâ.
In my experience you shouldnât rely on upstream apis to change, if you want to deliver a successful product. Sorry for the rant, but trying to get a good customer experience is really hard, if all you get as support is a đ¤ˇââď¸ with pointing to other (MS) teams. This is especially hard to sell, if those teams all work for the same company (Microsoft).
While the benefits of open sourcing everything are really overwhelmingly positive (kudos on that note!), it is frustrating to realize how fragmented the development teams have become. This critisism of course exempts all the hard working contributors out there that are pushing their free time into a product for pure love, that a company is later advertising for in their own name, and indirectly using to up cloud sales.
tl;dr. terraform is in my view currently the industry leader in IaC solution for clouds. MS to this day fails to properly support provisioning their only (and admittedly really great) reverse proxy solution in terraform. I do not have one customer not using AGW, so this makes this a blocking issue for us in multiple contexts, with many coleagues of mine being fed up with 1000s of lines of terraform changes for any go live. I will therefore advice building back terraform in favor of az / PowerShell regarding AGW, as this is a much more fool prove way to update it (contact me at forename.name@adesso.de and I will provide samples. This is not for privacy reasons, but the size of the scripts).
Forgive my frustration, but my collegues and I were looking forward to a fix for multiple years, and communicating the progress (documented above) to our customers, only to realize after days of migrations that this will not happen in the forseeable future, because âterraform or the Azure API will have to changeâ. đ
This is also making Application Gateways difficult to manage via Terraform for us, and we would appreciate a fix in an upcoming minor version, or transitioning to the next major version soon.
hi @johannespetereit, Iâm on the AzureRM team and Iâd like to talk with you more about this. I tried emailing you at the provided address (using your name as stated on your profile), but it keeps bouncing back. Would you like to sign up for a one-on-one with me?
Thatâs great news! Thanks for confirming @prubis