Fix error when changing route from virtual appliance to any other type

[draggeta]

There was a problem with changing from virtual appliance to any other type. This was caused by the fact that next_hop_in_ip_address was computed.

The issue occurred in both azurerm_route_table and azurerm_route.

Also made some other changes to make both resources similar.

• fix resource
• add tests to check for regression in future

Closes #1352

[draggeta]

There are a few linting errors from other resources. Those are optimizations. Should I fix them here or should they be fixed in separate pull requests?

[tombuildsstuff]

@draggeta sorry about the linting errors, they've been fixed via #2190 - I've re-run the build now that's been merged and this now passes 👍

[draggeta]

@tombuildsstuff No worries, I was the cause of one of them anyway 😊

[tombuildsstuff]

hey @draggeta

Thanks for this PR - on the whole this looks good to me, if we can update the test to ensure the next_hop_in_ip_address field is set to an empty string (unassigned) then this otherwise LGTM 👍

Thanks!

[tombuildsstuff]

hey @draggeta

Thanks for pushing those changes - this now LGTM 👍 - I'll kick off the tests shortly

Thanks!

[tombuildsstuff]

hey @draggeta

Running the tests I noticed one of them is failing due to the next_hop_in_ip_address field being conditionally set (and so this isn't set to an empty string):

------- Stdout: -------
=== RUN   TestAccAzureRMRoute_update
--- FAIL: TestAccAzureRMRoute_update (76.21s)
	testing.go:538: Step 0 error: Check failed: Check 3/3 error: azurerm_route.test: Attribute 'next_hop_in_ip_address' not found
FAIL

So that we can get this merged I've pushed a commit to fix this - I hope you don't mind!

Thanks!

[tombuildsstuff]

Tests pass:

[moisedo]

So in version 0.18 it was allowing to have this next_hop_in_ip_address null, but due to the verification it now needs a value if its specified. The big issue with this is, when you have N amount of routes per route table using a MAP, you cannot use a TF resource template anymore, you will have to create 2 templates (one for next_hop_in_ip_address and one without it) Is there another way to tackle this without duplicating code? Thank you. It will also allow me to understand the reason behind mandating a value on this key when is specified.

[ghost]

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!